investigations payments standards - exceptions and

UNIFI (ISO 20022) Message Definition Report

Edition August 2006

Payments Standards - Exceptions andInvestigations

Approved by UNIFI Payments SEG on 25 July 2006

Table Of Contents Overview .................................................................................................................................................................... 1

What does this document contain? ......................................................................................................................... 1Exceptions and Investigations messages ................................................................................................................ 1Business rationale for the Exceptions and Investigations messages ...................................................................... 1How to read ............................................................................................................................................................ 2

How to use the exceptions and investigations messages ........................................................................................ 3Introduction ............................................................................................................................................................ 3Concepts ................................................................................................................................................................. 3Rules ....................................................................................................................................................................... 4Case management main scenario ............................................................................................................................ 5Cancel case assignment scenario ............................................................................................................................ 7Request for duplicate instruction scenario .............................................................................................................. 8

Message Flows ........................................................................................................................................................... 9Request for cancellation scenario ........................................................................................................................... 9Request for modification scenario ........................................................................................................................ 11Claim non receipt scenario ................................................................................................................................... 17Unable to apply scenario ...................................................................................................................................... 22

Message: AdditionalPaymentInformation <camt.028.001.01> ...................................................................... 28Message Scope and Usage .................................................................................................................................... 28Message Structure ................................................................................................................................................. 29Message Items Description ................................................................................................................................... 30Business Example ................................................................................................................................................. 44

Message: CancelCaseAssignment <camt.032.001.01> .................................................................................... 49Message Scope and Usage .................................................................................................................................... 49Message Structure ................................................................................................................................................. 49Message Items Description ................................................................................................................................... 50Business Example ................................................................................................................................................. 52

Message: CaseStatusReport <camt.039.001.01> .............................................................................................. 58Message Scope and Usage .................................................................................................................................... 58Message Structure ................................................................................................................................................. 58Message Items Description ................................................................................................................................... 59Business Example ................................................................................................................................................. 64

Message: CaseStatusReportRequest <camt.038.001.01> ................................................................................ 67Message Scope and Usage .................................................................................................................................... 67Message Structure ................................................................................................................................................. 67Message Items Description ................................................................................................................................... 68Business Example ................................................................................................................................................. 70

Message: ClaimNonReceipt <camt.027.001.01> .............................................................................................. 73Message Scope and Usage .................................................................................................................................... 73Message Structure ................................................................................................................................................. 74Message Items Description ................................................................................................................................... 75Business Example ................................................................................................................................................. 79

Message: DebitAuthorisationRequest <camt.037.001.01> .............................................................................. 93Message Scope and Usage .................................................................................................................................... 93Message Structure ................................................................................................................................................. 93Message Items Description ................................................................................................................................... 94Business Example ................................................................................................................................................. 99

Message: DebitAuthorisationResponse <camt.036.001.01> ......................................................................... 104Message Scope and Usage .................................................................................................................................. 104Message Structure ............................................................................................................................................... 104

Message Items Description ................................................................................................................................. 105Business Example ............................................................................................................................................... 108

Message: NotificationOfCaseAssignment <camt.030.001.01> ...................................................................... 114Message Scope and Usage .................................................................................................................................. 114Message Structure ............................................................................................................................................... 115Message Items Description ................................................................................................................................. 115Business Example ............................................................................................................................................... 119

Message: RejectCaseAssignment <camt.031.001.01> ................................................................................... 126Message Scope and Usage .................................................................................................................................. 126Message Structure ............................................................................................................................................... 126Message Items Description ................................................................................................................................. 127Business Example ............................................................................................................................................... 130

Message: RequestForDuplicateInstruction <camt.033.001.01> ................................................................... 133Message Scope and Usage .................................................................................................................................. 133Message Structure ............................................................................................................................................... 133Message Items Description ................................................................................................................................. 134Business Example ............................................................................................................................................... 136

Message: RequestToCancelPayment <camt.008.002.01> ............................................................................. 139Message Scope and Usage .................................................................................................................................. 139Message Structure ............................................................................................................................................... 140Message Items Description ................................................................................................................................. 141Business Example ............................................................................................................................................... 145

Message: RequestToModifyPayment <camt.007.002.01> ............................................................................ 153Message Scope and Usage .................................................................................................................................. 153Message Structure ............................................................................................................................................... 155Message Items Description ................................................................................................................................. 157Business Example ............................................................................................................................................... 173

Message: ResolutionOfInvestigation <camt.029.001.01> .............................................................................. 185Message Scope and Usage .................................................................................................................................. 185Message Structure ............................................................................................................................................... 186Message Items Description ................................................................................................................................. 187Business Example ............................................................................................................................................... 194

Message: UnableToApply <camt.026.001.01> ............................................................................................... 196Message Scope and Usage .................................................................................................................................. 196Message Structure ............................................................................................................................................... 197Message Items Description ................................................................................................................................. 198Business Example ............................................................................................................................................... 204

Message Item Types .............................................................................................................................................. 223Data Types .......................................................................................................................................................... 223End Points ........................................................................................................................................................... 232

Indexes ................................................................................................................................................................... 268Index of Message Items ...................................................................................................................................... 268Index of XML tags ............................................................................................................................................. 281Index of Message Item Types ............................................................................................................................. 295

Errata ..................................................................................................................................................................... 305Definition for RejectionReason Code UKNW ................................................................................................... 305

Revision Record .................................................................................................................................................... 306

OverviewWhat does this document contain?This document describes a set of Payments Exceptions and Investigations messages approved by the Payments Standards Evaluation Group as UNIFI messages on 25 July 2006.The set of Exceptions and Investigations messages documented in this report is exchanged between case assigners and case assignees. The set supports the following payment-related investigation activities:1. Request to cancel payment: this request is initiated by the party that initiated the payment. It includes the

RequestForDebitAuthorisation and its confirmation, but excludes the return of funds.2. Request to modify payment: this request is initiated by the party that initiated the payment. It includes the

AdditionalInformation message sent to the beneficiary. 3. Unable to apply: this activity is initiated by a party instructed to make a payment or the beneficiary of the payment.4. Claim non-receipt: this activity is initiated by the party waiting for a payment. This party contacts its debtor. The

debtor creates a case and assigns it by sending the case to the party instructed to make the payment. The activity also covers missing cover situations.

These specific activities are supported by the concept of case management. The case management messages are:

Exceptions and Investigations messages- the ResolutionOfInvestigation message: this message provides a definite answer to the inquiry (positive or negative),

and enables the case assignee to close the case. - the NotificationOfCaseAssignment message: this message notifies the case assigner that a case has been assigned

to a next party in the payment chain.- the RequestForDuplicateInstruction message: this message requests a copy of the original transaction from the case

assigner/creator. It is used when the case assignee is not able to find the payment transaction that the enquiry is related to.

- the RejectCaseAssignment message: this message is sent from the case assignee when he does not have the payment transaction that the enquiry is related to.

- the CancelCaseAssignment message: this message is sent by the case creator and forwarded to the next case assignee if the case has been wrongly allocated or the case has been solved by other means.

- the CaseStatusReportRequest message: this message is used to request the status of a case under investigation.- the CaseStatusReport message: this message is used to provide the status of the case in response to a

CaseStatusReportRequest message.- the DebitAuthorisationRequest: this message is used to request debit authorisation from the creditor.- the DebitAuthorisationResponse message: this message is used by a creditor to provide an answer to a

DebitAuthorisationrequest message.- the AdditionalPaymentInformation message: this message is used to provide additional information about a payment

instruction.

Business rationale for the Exceptions and Investigations messages

In an average payments operations department, two to five percent of all payments made on any particular day result in an enquiry. In an effort to improve the competitive position of their cash management offerings, financial institutions are putting increasing pressure on their payments operations. While many processing units achieve impressive straight-through processing (STP) rates, it has become clear that the cost of handling each enquiry resulting from a payment is multiplied in the total payment cost.

Management of exceptions and investigations remains one of the most labour-intensive activities for a financial institution, largely because it blocks increased automation. The reason for this is the widespread use of free-format messages combined with a lack of industry rules.

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

Overview

Page 1

In response to increasing regulatory and competitive pressure, financial institutions are looking at implementing activity-based pricing, and at invoicing their payments services separately from the processing. This approach is designed to generate additional revenue. However, it requires a high level of service, supported by standardised customer reporting.

The fact remains that improving customer service levels though fast and efficient resolution of problems is a key differentiating factor for customer retention.

How to readIn compliance with ISO 20022, UML (Unified Modelling Language) is used to depict business and logical models. As knowledge of UML is not a requirement to discuss the business standards, the data format for the messages are presented in a user-friendlier way. This way of representation is automatically generated from the models, thereby ensuring absolute consistency between the model information and the published standard.


Overview

Page 2

How to use the exceptions and investigations messages

This section describes the context and various work flows supporting the Exceptions and Investigations processes.

Introduction

An exception or investigation process starts when a problem occurs in the normal execution of a payment transaction:- an expected payment is not received;- a payment is received but is incorrect;- a payment is received but some information is missing, preventing its processing;- a payment must be modified, following a decision by the party instructing the payment or due to a processing error;- a payment needs to be cancelled, following a decision by the party instructing the payment or due to a processing

error.

Four different types of exception and investigation processes have been covered and a corresponding set of messages developed:- Request for cancellation: occurs when the instructing party requests cancellation of a payment instruction.- Request for modification: occurs when the instructing party requests modification of a payment instruction.- Unable to apply: occurs when insufficient or incorrect information prevents the processing of a payment instruction,

eg, the account number is missing or incorrect, the account is closed, the name and account do not match, the final agent is missing. Processing of a payment instruction covers both the execution of the instruction and the reconciliation of the instruction.

- Claim non receipt: occurs when a party expecting a payment does not receive it or when an agent is missing the cover for a received payment instruction.

An exception or investigation process requires communication with several parties. It is therefore essential to clearly define the behaviour of each party involved and the communication between them. This may lead to an increased number of messages exchanged, but the exceptions and investigations processes become more efficient.

Each exception and investigation process is supported by a specific workflow. A workflow defines the set of messages to be exchanged between the parties and the sequence of exchanges.

This section contains the definition of a case management main scenario as well as related workflows explaining the basic principles supporting the four others. It also explains the main concepts driving the set of messages and the rules to be observed by the parties.

Concepts

The exception or investigation caseAn exception or investigation case is created each time an exception and investigation process needs to be initiated. This creation is internal to the party initiating an investigation workflow: the case creation and handling can be either electronic or paper-based. The steps in the process that follow the case creation can be either automated or manual. The first message exchanged in an investigation workflow is called a 'case assignment' message. There is one specific 'case assignment' message for each of the four activities:

Activity Case assignment message



Page 3

Request for cancellation RequestToCancelPayment

Request for modification RequestToModifyPayment

Unable to apply UnableToApply

Claim non receipt ClaimNonReceipt

Case creator, case assigner and case assignee The party creating the case is called the case creator.The case creator or any other party sending a case assignment message is called the case assigner.The party receiving a case assignment message is called the case assignee.

Case identificationThe case creator must assign an identification to the case. This identification will be repeated in all messages related to this case by all parties involved in the workflow.

Rules

Uniqueness of the case identificationThe identification of a case must be unique for the case creator. The case creator must assign the case identification in such a way that it ensures uniqueness (eg, if a sequential number is assigned to each case, the range of numbers should be large enough to avoid ambiguity when restarting the sequence).In order to make this identification unique for all the parties involved in the workflow, the BIC (or BEI) of the case creator will always be repeated together with the case identification.A simple approach is to combine a date followed with a sequential number (e.g. 20050603000001).

The 'no by-pass' ruleEach workflow specifies the parties that a case can be assigned to. For example, a request for cancellation case assignment follows the route of the payment instruction (from instructing party to instructed party), while the unable to apply case assignment is sent in the opposite direction (from the instructed party to the instructing party).

The following table summarises the direction of the various investigation activities:

Activity Case assignment message Case assigner Case assignee

Request for cancellation

RequestToCancelPayment Instructing party Instructed party/creditor

Request for modification

RequestToModifyPayment Instructing party Instructed party/creditor

Unable to apply UnableToApply Instructed party/creditor Instructing party

Claim non receipt * ClaimNonReceipt Instructing party Instructed party

* the claim non receipt activity encompasses the missing cover situation, which has a different behaviour: the case is first assigned by the final agent to the first agent and then follows the route of the payment instruction (cover payment).

The 'no by-pass' rule specifies that no party involved in the original payment transaction can be by-passed in the exception and investigation workflow. It also specifies that all parties involved in an investigation workflow must be kept informed of the status of the investigation at all times. It means that:



Page 4

- the ResolutionOfInvestigation message must be sent by the party solving the investigation to the case assigner. This ResolutionOfInvestigation message must be forwarded to all preceding case assignees until it reaches the case creator.

- each time a case is assigned to another party, the party must notify this new assignment to its case assigner. This NotificationOfAssignment message must also be forwarded up to the case creator.

Note: In the transition phase, not all financial institutions will be using the exceptions and investigations service. Some workflows are likely to involve financial institutions that have not yet implemented the principles described in this document. Each member of the service should try to follow these principles with other parties, even if a workflow involves a party that is not a member of this service.

Case management main scenario

This section describes the generic workflow supporting the four specific activities covered in the scope of the exception and investigation message set.

A B C D

1.CaseAssignment2.CaseAssignment

4. CaseAssignment3. NotificationOfAssignment

5. Notificat ionOfAssignment

6. NotificationOfAssignment

7.ResolutionOfInvestigation8.ResolutionOfInvestigation

9.ResolutionOfInvestigation

Step 1: A assigns a case to B

A case is assigned to another party by sending one of the four case assignment messages: RequestToCancelPayment, RequestToModifyPayment, UnableToApply or ClaimNonReceipt.

When a case is assigned to a case assignee, the case assignee must first check the validity of the assignment. The assignment is valid if the following two conditions are met:1. the case assignee can retrieve the underlying payment instruction (the instruction under investigation) and this

instruction has not been rejected or cancelled.2. the assignee is entitled to investigate the underlying payment instruction (eg, a request for cancellation assigned by

the final agent to the debtor does not make sense). Generally speaking, a case can be assigned by a case assigner to a case assignee if the underlying instruction was exchanged between the same two parties.



Page 5

If the assignment is valid, the case assignee must check that there is no other case open on this underlying instruction.

If there is no other case open for the same payment instruction, the case assignee must accept the case. Acceptance is implicit. There is no specific acceptance message sent to the case assigner.

If there is another case open on the same payment instruction, the case assignee can request the closure of one of the open cases. This is achieved by sending a ResolutionOfInvestigation message with the identification of the case to be closed.

If there is another case open on the same payment instruction the case assignee can request the cancellation of the duplicate case assignment by sending a CancelCaseAssignment. The CancelCaseAssignment message is answered by a ResolutionOfInvestigation message with AssignmentCancellationConfirmation set to 'yes'.

If the assignment is not valid, it must be rejected.

This is achieved by sending a RejectCaseAssignment message to the case assigner with the CaseAssignmentRejectionCode set to value:

NFND UnderlyingPaymentNotFound

The underlying payment instruction cannot be found.

NAUT NotAuthorisedToInvestigate The case assignee is not allowed to investigate this instruction (eg, case assignee is not the next party in the payment chain).

UKNW UnknownCase Used when receiving a ResolutionOfInvestigation or a DebitAuthorisation for an unknown case. It can also be used when a party rejects a case status request.

RJCT Rejected The payment instruction has been rejected.

CNCL Cancelled The payment instruction has been cancelled.

If the case assignee does not have enough information to retrieve the underlying instruction, it can request a copy of the original instruction (see the request for duplicate instruction workflow below).

Step 2: B assigns the case to C.If the case assignee is not able to solve the case and assumes the next party is able to resolve the case, the case assignment message is forwarded to the next party in the payment instruction processing chain.

Step 3: B sends a NotificationOfCaseAssignment to A.After assigning the case to the next party, B informs A of the new assignment of the case.

Step 4: C assigns the case to D.

Step 5: C sends a NotificationOfAssignment to B.After assigning the case to the next party, C informs B of the new assignment of the case.

Step 6: B forwards the NotificationOfAssignment to A.B informs A of the new assignment of the case to D.

Step 7: D sends a ResolutionOfInvestigation to C.After solving the case, D sends a ResolutionOfInvestigation to C.



Page 6

Step 8: C forwards the ResolutionOfInvestigation to B.

Step 9: B forwards the ResolutionOfInvestigation to A.

Cancel case assignment scenarioThis workflow can be initiated by the case assigner wanting to stop the processing of a case. It must be answered with a ResolutionOfInvestigation message expressing a positive or negative answer.It must be forwarded by all subsequent case assigners/case assignees until it reaches the case creator. If the first CancelCaseAssignment message is sent by the case creator, it will result in the case being cancelled. If it is sent by an intermediate assigner, only the assignment initiated by this party (and their potential subsequent assignments) will be cancelled.

A B C1. CaseAssignment

6. ResolutionOfInvestigation

3. CancelAssignement

2. CaseAss ignment

4. CancelAssignement

5. ResolutionOfInvestigation

Step 1: A assigns a case to B.

Step 2: B assigns a case to C.

Step 3: A requests the cancellation of the previous assignment by sending a CancelCaseAssignment message to B.



Page 7

Step 4: B forwards the request to C by sending a similar CancelCaseAssignment message to C.

Step 5: C replies to B with a ResolutionOfInvestigation message. Depending on the result of the request, the ResolutionOfInvestigation will contain an element (AssignmentCancellationConfirmation) set to 'yes' (cancellation confirmed) or 'no' (cancellation rejected).

Step 6: B forwards to A the response received from C.

Request for duplicate instruction scenarioThis scenario can be initiated by a case assignee that does not have enough information to retrieve the underlying instruction. In such a case, the case assignee can request a copy of the original instruction. This is achieved by sending a RequestForDuplicateInstruction message. It will be answered by a DuplicateInstruction message.

A B

CaseAssignment

RequestForDuplicateInstruction

DuplicateInstruction

Step 1: The case assigner assigns the case to the case assignee.

Step 2: The case assignee needs more information and requests a duplicate of the payment instruction referenced in the case using the RequestForDuplicateInstruction message.

Step 3: The case assigner returns a duplicate of the payment instruction using a DuplicateInstruction message. Note that this message can be used to return duplicates of a payment instruction in any format (eg, XML, FIN, EDIFACT, proprietary, ...).



Page 8

Message FlowsRequest for cancellation scenario

This scenario describes the workflow to cancel a payment instruction.

The party willing to cancel a payment instruction, ie, the debtor, first agent or any other agent involved in the payment instruction processing chain determines the case identification and the information necessary to identify the underlying payment and sends a RequestToCancelPayment message to its case assignee.

One of the following values must be used within the RequestToCancelPayment message to specify the reason for cancellation:

Cancellation Reason Codes

AGNT IncorrectAgent An agent in the payment workflow is incorrect.

DUPL DuplicatePayment The payment is a duplicate of another payment.

CURR IncorrectCurrency The currency of the payment is incorrect.

UPAY UnduePayment The payment is not justified.

CUST RequestedByCustomer Cancellation is requested by the debtor.

When the message reaches the case assignee: - the payment instruction may have been successfully processed,- the payment instruction may be pending execution,

or- the cancellation cannot be performed, eg, the request for cancellation case is outside the agreed limits or when the

payment instruction has been unsuccessfully processed.

If the payment has been successfully processed, the case assignee must:- forward the RequestToCancelPayment message to the next agent.

The RequestToCancelPayment message is sent to the next agent in the payment chain. The current agent becomes the case assigner and the next agent in the payment chain becomes the case assignee. The message sent is similar to the one received: the case identification and the reason for the cancellation remain the same. The identification of the underlying payment may be different: it must always be the identification used between the case assigner and the case assignee.

- reply with a NotificationOfCaseAssignment message to the case assigner. This message contains the case identification and a CaseForwardingNotification1Code with value:

FTHI FurtherInvestigation Case has been forwarded to the next party for further investigation.

If the payment is still pending execution, the case assignee:- can perform the cancellation,

and- sends a positive ResolutionOfInvestigation message to its case assigner. This message contains the case

identification and InvestigationExecutionConfirmation1Code with value:

CNCL CancelledAsPerRequest Returned when a requested cancellation is successful.


Message Flows

Page 9

If the request for cancellation cannot be performed, the ResolutionOfInvestigation message is used to reject the request. This message then contains a PaymentCancellationRejection1Code with one of the following values:

LEGL LegalDecision Reported when the cancellation cannot be accepted because of regulatory rules.

AGNT AgentDecision Reported when an agent refuses to cancel.

CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (creditor).

When the case is assigned to the final agent and the payment has already been processed successfully, he must:- send a DebitAuthorisationRequest to the creditor.

This message must contain the case identification as in the RequestToCancelPayment. The underlying payment identification must be the identification appearing on the statement or the credit advice sent to the creditor. The reason for cancellation must be identical to the one received in the RequestToCancelPayment message.

- reply with a NotificationOfCaseAssignment message to the case assigner. This message will indicate that a request for debit authorisation has been issued to the creditor. The CaseForwardingNotification1Code is set to value:

DTAU RequestDebitAuthorisation Case has been forwarded to obtain authorisation to debit.

The creditor sends a DebitAuthorisationResponse to the final agent. This message must contain a DebitAuthorisationIndicator set to yes or no, depending on the decision of the creditor.

This response triggers the issuance by the final agent of a ResolutionOfInvestigation message to the preceding case assigner and up to the case creator.

When the response is positive, the InvestigationExecutionConfirmation1Code is set with value:

CNCL CancelledAsPerRequest Returned when a requested cancellation is successful.

When the response is negative, the PaymentCancellationRejection1Code is set with value:

CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (creditor).

An optional reason in the form of a text (max. 140 characters) can be added to the code.


Message Flows

Page 10

Request for cancellation

Debtor FirstAgent FinalAgent Creditor

RequestToCancelPayment

RequestToCancelPayment

Notificat ionOfAssignmentDebitAuthorisationRequestNotificationOfAssignment

Notificat ionOfAssignment

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


Message Flows

Page 11

InstructionCode Up to last instructed party

RequestedExecutionDate Up to first instructed party

ValueDate Up to last instructed party

InterbankSettledAmount Up to last instructed party

Debtor Up to creditor

DebtorAccount Up to first instructed party

IntermediarySettlementAgent Up to next instructed agent

LastSettlementAgent Up to next instructed agent

PaymentScheme Up to next instructed agent

BeneficiaryInstitutionAccount Up to last instructed party

Creditor Up to last instructed party

CreditorAccount Up to last instructed party

Remittance information Up to creditor

Purpose Up to creditor

Instruction for final agent Up to last instructed agent

DetailsOfCharges Up to creditor

SenderToReceiverInformation Up to next instructed agent

On the case assignee's side, the following situations may occur:- the payment instruction has been cancelled, rejected or returned. This means the modification cannot take place and

the case assigner will be notified through the RejectCaseAssignment message.- the payment instruction has been successfully processed. The case assignee will forward the

RequestToModifyPayment message to the next instructed party (eg, if the remittance information needs to be modified). The case assignee sends a NotificationOfCaseAssignment message to the case assigner/case creator.

- the payment instruction is still pending execution at the case assignee and the modification can take place. The case assignee sends a ResolutionOfInvestigation message to the case assigner with the InvestigationExecutionConfirmation1Code element set to value MODI (ModifiedAsPerRequest).

- the payment instruction is still pending execution at the case assignee but the case assignee prefers not to modify the payment instruction (eg, for security reasons) and opts for a cancellation of the original payment instruction.The case assignee sends a ResolutionOfInvestigation message to the case assigner with the PaymentModificationRejection1Code element set to value UM20 (InstructionCancelledSubmitNewInstruction).

- the payment instruction is still pending execution at the case assignee and one of the elements cannot be successfully modified. The whole RequestToModifyPayment is rejected. The case assignee sends a negative ResolutionOfInvestigation message. At least one occurrence of the PaymentModificationRejection1Code element must contain one of the codes from the table below. If several elements of the request cannot be modified, then several occurrences of the PaymentModificationRejection1Code element can be used.

UM01 UnableToModifyRelatedReference RelatedReference cannot be modified.

UM02 UnableToModifyBankOperationCode BankOperationCode cannot be modified.

UM03 UnableToModifyInstructionCode InstructionCode cannot be modified.

UM04 UnableToModifyRequestedExecutionDate RequestedExecutionDate cannot be modified.


Message Flows

Page 12

UM05 UnableToModifyValueDate ValueDate cannot be modified.

UM06 UnableToModifyInterbankSettlementAccount InterbankSettlementAccount cannot be modified.

UM07 UnableToModifyDebtor Debtor cannot be modified.

UM08 UnableToModifyDebtorAccount DebtorAccount cannot be modified.

UM09 UnableToModifyReceiverCorrespondent ReceiverCorrespondent cannot be modified.

UM10 UnableToModifyThirdReimbursementInstitution ThirdReimbursementInstitution cannot be modified.

UM11 UnableToModifyPaymentScheme PaymentScheme cannot be modified.

UM12 UnableToModifyAccountOfBeneficiaryInstitution AccountOfBeneficiaryInstitution cannot be modified.

UM13 UnableToModifyCreditor Creditor cannot be modified.

UM14 UnableToModifyCreditorAccount CreditorAccount cannot be modified.

UM15 UnableToModifyRemittanceInformation RemittanceInformation cannot be modified.

UM16 UnableToModifyPaymentPurpose PaymentPurpose cannot be modified.

UM17 UnableToModifyDetailsOfCharges DetailsOfCharges cannot be modified.

UM18 UnableToModifySenderToReceiverInformation SenderToReceiver cannot be modified.

UM19 UnableToModifyInstructionForFinalAgent InstructionForFinalAgent cannot be modified.

UM20 InstructionCancelledSubmitNewInstruction Used to inform of cancellation and request a new payment instruction. This should only be used if an agent does not want to modify a pending payment.

UM21 UnableToModifySubmitCancellation Modification is not possible and the cancellation is requested.


Message Flows

Page 13

Request for modification

Debtor : CorporateApplication

FirstAgent : FinancialInstAppli...

FinalAgent : Financ ialInstAppli.. .

Creditor : CorporateApplication

RequestToModifyPaymentRequestToModifyPayment

RequestToModifyPaymentNotificationOfCaseAssignment

Notificat ionOfCaseAssignment

NotificationOfCaseAssignment




Modification of the payment instruction amount scenario

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


Message Flows

Page 14

- if the amount of the original payment instruction is higher than the amount to be effectively paid to the creditor, the case assignee performing the modification must return the funds to the case assigner. This means that in some circumstances, the final agent will have to request debit authorisation from the creditor (when the payment instruction has been successfully processed up to the creditor).

- if the amount of the original payment instruction is lower than the amount to be effectively paid to the creditor, the case creator must send a new payment instruction to meet the difference. The latter action is not considered as an investigation case.

Request for modification when the amount is lower than the original amount

Debtor FirstAgent FinalAgentCreditor


DebitAuthorisationRequest

DebitAuthorisationResponseResolutionOfInvestigation


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


Message Flows

Page 15

3. the RequestToModifyPayment partially contradicts the payment instruction (eg, amount paid in excess): this requires partial debit authorisation from the creditor. A DebitAuthorisationRequest must be sent to the creditor (please refer to the RequestToCancelPayment workflow for more details).

Request for modification followed by a cancellation

Debtor First Agent Final Agent Creditor

RequestToModifyPaymentRequestToCancelPayment

NotificationOfAssignment

ResolutionOfInvestigationResolut ionOfInvest igation



NotificationOfAssignmentNotificationOfAssignment


Message Flows

Page 16

Claim non receipt scenario

A claim non receipt case is initiated by the originator of the payment instruction (usually the debtor). The creditor may also ask its financial institution whether a payment has arrived. This possibility is considered marginal and not retained as a workflow in this set of standards.The workflow exclusively considers that the party expecting a payment contacts its debtor. The debtor creates a case and assigns the case to its first agent by sending a ClaimNonReceipt message. The case assignee checks the status of the received payment instruction. The payment instruction can be pending, rejected or cancelled, or executed:

1. if the payment instruction is pending, the case assignee confirms the instruction will be executed with a ResolutionOfInvestigation message. The case assignee sends a ResolutionOfInvestigation message to the case assigner. The ResolutionOfInvestigation message contains the InvestigationExecutionConfirmation1Code element set to value IPYI (PaymentInstructionInitiated).

2. if the payment instruction has been rejected or cancelled, the case assignee notifies the rejection or cancellation with a RejectCaseAssignment message.

3. if the payment instruction has been executed: the case assignee checks the execution status. Different actions can be taken:

3.1. if the payment instruction was correctly executed and the payment is 'not on us', the case assignee forwards the claim non receipt case to the next agent in the payment processing chain (by means of a ClaimNonReceipt message). This message is similar to the one received: the case identification remains the one assigned by the case creator. The identification of the underlying instruction may be different: it must be the identification used between the case assigner and the case assignee. This message must be followed by a NotificationOfCaseAssignment sent to the case assigner. This message simply contains the case identification and a CaseForwardingNotificationCode set to value FTHI (FurtherInvestigation).

3.2. if the payment instruction execution was correctly executed and the payment is 'on us', the case assignee returns the identification of the payment with a ResolutionOfInvestigation message (in the CorrectionTransaction component). Following reception of this message, the case assigner should close the case. This message contains in the InvestigationExecutionConfirmation1Code element set to value CONF (ConfirmationOfPayment).

3.3. if the payment instruction was incorrectly executed, the case assignee will initiate a RequestToCancelPayment or a RequestToModifyPayment.

When a cancellation is required, the case assignee initiates a correct payment and returns its identification to the case assigner with a ResolutionOfInvestigation message (within the CorrectionTransaction component). This ResolutionOfInvestigation message contains the InvestigationExecutionConfirmation1Code element set to value IPAY (PaymentInitiated) . The ResolutionOfInvestigation message will be forwarded up to the case creator.

When a modification is required, the case assignee sends a RequestToModifyPayment message to the next party. A NotificationOfCaseAssignment message must be sent to the initial case assigner. This message simply contains the case identification and a CaseForwardingNotificationCode set to value MODI (RequestToModify).


Message Flows

Page 17

Claim non receipt



FinalAgent : FinancialInstAppli...


ClaimNonReceipt

ClaimNonReceiptNotificationOfAssignment

Not ificationOfAssignmentAdditionalPaymentInformation






Message Flows

Page 18

Claim non receipt followed by a modification


ClaimNonReceiptClaimNonReceipt


NotificationOfAssignmentNotificationOFAssignment

RequestToModifyPayment

Resolut ionOfInvestigationResolutionOfInvestigation



Message Flows

Page 19

Claim non receipt followed by a cancellation


ClaimNonReceipt

ClaimNonReceipt



This party needs to cancel an instruct ion and initiates a new instruc tion.

Resolut ionOfInvestigation

Missing cover scenario

The missing cover situation is considered part of the claim non receipt case.

The missing cover corresponds to the situation where an agent has received a payment instruction (eg, MT 103) and is missing the cover (eg, MT 202).

The agent missing the cover is the case creator and assigns the case to the sender of the payment instruction (eg, MT 103). The ClaimNonReceipt message contains a specific MissingCoverIndicator element to stipulate the cover is missing which must be set to yes.

Upon receipt, the case assignee checks the execution of the cover instruction and the payment instruction:

- if the cover instruction (eg, MT 202) was sent correctly (ie, identical to the payment instruction elements), the missing cover case must be forwarded to the first settlement agent (the receiver of MT 202) for investigation. This agent in turn will also check if the cover has been executed correctly.

- if the cover instruction was not sent, the case assignee can either initiate the cover instruction (MT 202) or confirm that the cover instruction is not required and cancel the payment instruction (MT103).


Message Flows

Page 20

When the cover instruction needs to be initiated, the case assignee returns a ResolutionOfInvestigation message with the InvestigationExecutionConfirmation1Code element set to ICOV (CoverInitiated).

When the payment instruction needs to be cancelled, the case assignee returns a ResolutionOfInvestigation message with the InvestigationExecutionConfirmation1Code element set to CWFW (CancellationWillFollow).

- if the cover instruction was sent incorrectly, the case assignee can either modify or cancel the cover instruction.

When the cover instruction needs to be modified (eg, wrong creditor's account), the case assignee sends a RequestToModifyPayment message to the next party in the cover instruction processing chain. This case assignee, upon completion of the modification, returns a ResolutionOfInvestigation to its case assigner with the InvestigationExecutionConfirmation1Code element set to MCOV (CoverModified).

When the cover instruction needs to be cancelled (eg, wrong creditor), the case assignee sends a RequestToCancelPayment message and initiates a new cover instruction. This request for cancellation must be considered as a separate case. The new instruction must be initiated and its reference must be returned in the CorrectionTransaction element of the ResolutionOfInvestigation message. The InvestigationExecutionConfirmation1Code element must be set to ICOV (CoverInitiated).


Message Flows

Page 21

Missing cover

FirstAgent Firs tSettlementAgent ...

LastSettlementAgent ...

FinalAgent

ClaimNonReceipt


2. ClaimNonReceipt

ClaimNonReceipt



ResolutionOfInvestigationResolutionOfInvest igation

Unable to apply scenario

The unable to apply scenario covers two main situations:- a payment instruction has been received, but incorrect/missing payment information prevents its processing (unable

to execute);


Message Flows

Page 22

- a payment instruction or entry has been received, but incorrect/missing payment information prevents its reconciliation (unable to apply).

The unable to apply scenario describes how to request additional information when a party has received a payment instruction and is unable to apply or execute.

The party that is unable to apply or execute a payment instruction creates an investigation case and assigns the case to its instructing party by sending an UnableToApply message.

The case creator determines the case identification and the information necessary to identify the underlying payment. The underlying payment identification should be the one used by the case assignee (eg, the entry identification or the payment instruction identification).

The case creator must indicate the reason for assigning the case.

The UnableToApply message provides the possibility to specifically indicate the element from the payment instruction that is either missing or incorrect (within the MissingOrIncorrectInformation element).

The following list is used to identify incorrect information from the payment instruction:

IN01 IncorrectRelatedReference Related reference is incorrect.

IN02 IncorrectBankOperationCode Bank operation code is incorrect.

IN03 IncorrectInstructionCode Instruction code is incorrect.

IN04 IncorrectRequestedExecutionDate Requested execution date is incorrect.

IN05 IncorrectValueDate Value date is incorrect.

IN06 IncorrectInterbankSettledAmount Interbank settled amount is incorrect.

IN07 IncorrectDebtor Debtor is incorrect.

IN08 IncorrectDebtorAccount Debtor account is incorrect.

IN09 IncorrectReceiverCorrespondent Receiver correspondent is incorrect.

IN010 IncorrectThirdReimbursementInstitution Third reimbursement institution is incorrect.

IN011 IncorrectPaymentScheme Payment scheme is incorrect.

IN012 IncorrectAccountOfBeneficiaryInstitution Account of Beneficiary institution is incorrect.

IN013 IncorrectCreditor Creditor is incorrect.

IN014 IncorrectCreditorAccount Creditor account is incorrect.

IN15 IncorrectRemittanceInformation Remittance information is incorrect.

IN16 IncorrectPaymentPurpose Payment purpose is incorrect.

IN17 IncorrectDetailsOfCharges Details of charges is incorrect.

IN18 IncorrectSenderToReceiverInformation Sender to receiver information is incorrect.

IN19 IncorrectInstructionForFinalAgent Instruction for Final Agent is incorrect.

MM20 MismatchCreditorNameAccount Name and Account of Creditor mismatch.

MM21 MismatchDebtorNameAccount Name and Account of Debtor mismatched.

MM22 MismatchFinalAgentNameAccount Name and Account of Final Agent mismatched.


Message Flows

Page 23

The following list is used to identify missing information from the payment instruction:

MS01 MissingRemittanceInformation Remittance Information is missing.

MS02 MissingSenderToReceiverInformation Sender To Receiver Information is missing.

MS03 MissingDebtor Debtor is missing.

MS04 MissingDebtorAccount Debtor Account is missing.

MS05 MissingFirstAgent First Agent is missing.

MS06 MissingAmount Missing Amount

MS07 MissingNostroVostroAccount Nostro Vostro Account is missing.

MS08 MissingIntermediary Intermediary is missing.

MS09 MissingReimbursementAgent1 Reimbursement Agent (Field 53) is missing.

MS10 MissingReimbursementAgent2 Reimbursement Agent (Field 54) is missing.

MS11 MissingReimbursementAgent Reimbursement Agent (Field 55) is missing.

MS12 MissingCreditor Creditor is missing.

MS13 MissingCreditorAccount Creditor Account is missing.

MS14 MissingInstruction Indicates the payment instruction (MT103) is missing.

The case assignee checks the execution of the payment instruction. The result of this check can either be positive (payment instruction executed correctly) or negative (payment instruction executed incorrectly).

If the payment instruction was correctly executed, and if more information is available at the case assignee, the case assignee can send additional information when available to allow reconciliation by sending an AdditionalPaymentInformation message to the case assigner. The case assignee can decide to send all the additional information instead of only returning the missing or additional information.

If the payment instruction was correctly executed, and if no further information is available at the case assignee, the case assignee can assign the case by forwarding an UnableToApply message to the preceding agent. The sender identifies itself as the case assigner and the previous instructing party in the payment processing chain is the case assignee. The case identification remains the same. The identification of the underlying payment should become the case assignee's identification (eg, field 20 of the FIN message or InstructionReference of an XML payment instruction). In the latter case, the case assignee must send a NotificationOfCaseAssignment message to the case assigner.

If the payment instruction was incorrectly executed, the case assignee can either:- request the modification of the payment instruction by sending a RequestToModifyPayment message to the case

assigner,

or- request the cancellation of the payment instruction by sending a ResolutionOfInvestigation message with the

InvestigationExecutionConfirmation1Code set to CWFW (CancellationWillFollow) and by sending a RequestToCancelPayment message afterwards.


Message Flows

Page 24

Unable to apply followed by sending additional information





UnableToApplyUnableToApply

UnableToApply

AdditionalPaymentInformation



Not ificationOfAssignment

NotificationOfAssignmentNotificationOfAssignment


Message Flows

Page 25

Unable to apply followed by a request for cancellation





UnableToApply

UnableToApply

UnableToApplyNotificationOfAssignment

Notificat ionOfAssignment


RequestToCancelPaymentRequestToCancelPayment






Message Flows

Page 26

Unable to apply followed by a request for modification

Debtor FirstAgent CreditorFinalAgent

UnableToApply

UnableToApplyUnableToApply NotificationOfAssignment

Notificat ionOfAssignment NotificationOfAssignment


RequestToModifyPayment

ResolutionOfInvestigationResolut ionOfInvest igation

Resolut ionOfInvest igation


Message Flows

Page 27

Message: AdditionalPaymentInformation <camt.028.001.01>Message Scope and UsageScope

The AdditionalPaymentInformation message is sent by an account servicing institution to an account owner.

This message is used to provide additional or corrected information on a payment instruction or statement entry, in order to allow reconciliation.

Usage

The AdditionalPaymentInformation message provides elements which are usually not reported in a statement or advice message (eg, full remittance information, or identification of parties other than the account servicing institution and the account owner). It complements information already received about a payment instruction, in the form of an entry or copy of the original payment instruction.

The AdditionalPaymentInformation message covers one and only one original payment instruction. If several payment instructions need to be supplemented, multiple AdditionalPaymentInformation messages must be used.

The AdditionalPaymentInformation message is used in a:- ClaimNonReceipt workflow: when the processing of the payment instruction is complete, the account owner receives

further particulars or corrected information for its reconciliation processes.- RequestToModifyPayment workflow: when the processing of the payment instruction is complete and the

modification does not affect the accounting at the account servicing institution, the account owner receives further particulars or corrected information about a payment instruction or an entry passed to its account.

The AdditionalPaymentInformation message cannot be used to trigger a request for modification of a payment instruction activity. A RequestToModifyPayment message must be used.

In the majority of cases, the AdditionalPaymentInformation message provides sufficient information to close the case. A ResolutionOfInvestigation message can be used as a reply to close the case and inform previous parties in the chain.

OutlineThe AdditionalPaymentInformation message is composed of four building blocks.

A.Case AssignmentThis building block is mandatory.

B.CaseThis building block is mandatory.

C.Payment Instruction ExtractThis building block is optional.


Message: AdditionalPaymentInformation <camt.028.001.01>

Page 28

D.Payment Complementary InformationThis building block is mandatory.

Message Structure

Index Or Message Item <XML Tag> Mult. Represent./Type

Rule/ Guid.

No.1.0 Assignment <Assgnmt> [1..1]

1.1 Identification <Id> [1..1] Text

1.2 Assigner <Assgnr> [1..1] Identifier

1.3 Assignee <Assgne> [1..1] Identifier

1.4 CreationDateTime <CreDtTm> [1..1] DateTime


Rule/ Guid.

No.2.0 Case <Case> [1..1]


2.2 Creator <Cretr> [1..1] Identifier

2.3 ReopenCaseIndication <ReopCaseIndctn> [0..1] Indicator


Rule/ Guid.

No.3.0 Underlying <Undrlyg> [1..1]

3.1 AssignerInstructionIdentification <AssgnrInstrId> [0..1] Text

3.2 AssigneeInstructionIdentification <AssgneInstrId> [0..1] Text

3.3 CurrencyAmount <CcyAmt> [0..1] Amount

3.4 ValueDate <ValDt> [0..1] DateTime


Rule/ Guid.

No.4.0 Information <Inf> [1..1]

4.1 RemittanceChoice <RmtChc> [0..1]

4.2 {Or Unstructured <Ustrd> [1..1] Text



Page 29


Rule/ Guid.

No.4.3 Or} Structured <Strd> [1..1]

4.4 ReferredDocumentType <RfrdDocTp> [0..1] Code

4.5 ReferredDocumentRelatedDate <RfrdDocRltdDt> [0..1] DateTime

4.6 ReferredDocumentAmount <RfrdDocAmt> [0..n]

4.7 {{Or DuePayableAmount <DuePyblAmt> [1..1] Amount

4.8 Or DiscountAppliedAmount <DscntApldAmt> [1..1] Amount

4.9 Or RemittedAmount <RmtdAmt> [1..1] Amount

4.10 Or CreditNoteAmount <CdtNoteAmt> [1..1] Amount

4.11 Or}} TaxAmount <TaxAmt> [1..1] Amount

4.12 DocumentReferenceNumber <DocRefNb> [0..1] Text

4.13 CreditorReference <CdtrRef> [0..1] Text

4.14 Invoicer <Invcr> [0..1] +

4.15 Invoicee <Invcee> [0..1] +

4.16 Debtor <Dbtr> [0..1] +

4.17 DebtorAccount <DbtrAcct> [0..1] +

4.18 FirstAgent <FrstAgt> [0..1] +

4.19 Amount <Amt> [0..1]

4.20 {Or InstructedAmount <InstdAmt> [1..1] Amount

4.21 Or} EquivalentAmount <EqvtAmt> [1..1]

4.22 Amount <Amt> [1..1] Amount

4.23 CurrencyOfTransfer <CcyOfTrf> [1..1] Code

4.24 NostroVostroAccount <NstrVstrAcct> [0..1] +

4.25 Intermediary <Intrmy> [0..1] +

4.26 FirstSettlementAgent <FrstSttlmAgt> [0..1] +

4.27 LastSettlementAgent <LastSttlmAgt> [0..1] +

4.28 IntermediarySettlementAgent <IntrmySttlmAgt> [0..1] +

4.29 Creditor <Cdtr> [0..1] +

4.30 CreditorAccount <CdtrAcct> [0..1] +

4.31 SenderToReceiverInformation <SndrToRcvrInf> [0..6] Text

Message Items DescriptionThe following section identifies the elements of the AdditionalPaymentInformation message.

1.0 Assignment <Assgnmt>Presence: [1..1]



Page 30

Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):






1.1 Identification <Id>Presence: [1..1]Definition: Identification of an assignment within a case.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

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

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

Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.

Example: <Assgnr>CORPBE22</Assgnr>

1.3 Assignee <Assgne>Presence: [1..1]Definition: Party that the case is assigned to. This is also the receiver of the message.



1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.



Page 31

Data Type: ISODateTime

2.0 Case <Case>Presence: [1..1]Definition: Identifies the case.Type: The Case block is composed of the following Case element(s):





2.1 Identification <Id>Presence: [1..1]Definition: Unique id assigned by the case creator.

Data Type: Max35TextFormat: maxLength: 35

minLength: 1Example: <Id>Case001</Id>

2.2 Creator <Cretr>Presence: [1..1]Definition: Party that created the case.



Example: <Cretr>CORPUK33</Cretr>

2.3 ReopenCaseIndication <ReopCaseIndctn>Presence: [0..1]Definition: Set to yes if the case was closed and needs to be re-opened.Data Type: One of the following YesNoIndicator values must be used:

MeaningWhenTrue: YesMeaningWhenFalse: No

3.0 Underlying <Undrlyg>Presence: [1..1]



Page 32

Definition: Identifies the underlying payment instruction.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):






3.1 AssignerInstructionIdentification <AssgnrInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assigner.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2 AssigneeInstructionIdentification <AssgneInstrId>Presence: [0..1]Definition: Identification of the payment instruction (eg, field 20 of an MT 103) when meaningful to the case assignee.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.3 CurrencyAmount <CcyAmt>Presence: [0..1]Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or

the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount

fractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}

Rule(s): CurrencyCodeValidationByTable

3.4 ValueDate <ValDt>Presence: [0..1]Definition: Value date of the payment.Data Type: ISODateTime



Page 33

4.0 Information <Inf>Presence: [1..1]Definition: Additional information to the underlying payment instruction.Type: The Information block is composed of the following PaymentComplementaryInformation element(s):


4.1 RemittanceChoice <RmtChc> [0..1]

4.16 Debtor <Dbtr> [0..1] +


4.18 FirstAgent <FrstAgt> [0..1] +

4.19 Amount <Amt> [0..1]

4.24 NostroVostroAccount <NstrVstrAcct> [0..1] +

4.25 Intermediary <Intrmy> [0..1] +

4.26 FirstSettlementAgent <FrstSttlmAgt> [0..1] +






4.1 RemittanceChoice <RmtChc>Presence: [0..1]Definition: Remittance information.Type: This message item is composed of one of the following RemittanceInformation3Choice element(s):



4.3 Or} Structured <Strd> [1..1]

4.2 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 4.1 RemittanceChoice.Definition: Information, in free text form, to enable the matching, ie reconciliation, (reconciliation) of a payment with

the items that the payment is intended to settle, such as commercial invoices in an accounts receivable system.Data Type: Max140TextFormat: maxLength: 140

minLength: 1



Page 34

4.3 Structured <Strd>Presence: [1..1]This message item is part of choice 4.1 RemittanceChoice.Definition: Information in structured form, that is supplied to enable the matching, ie, reconciliation, of a payment with

the items that the payment is intended to settle, eg, commercial invoices in an account receivable system. Type: This message item is composed of the following StructuredRemittanceInformation2 element(s):









4.4 ReferredDocumentType <RfrdDocTp>Presence: [0..1]Definition: Specifies the nature of the referred document/transaction, eg, invoice or credit note.Data Type: CodeWhen this message item is present, one of the following DocumentType1Code values must be used:

Code Name DefinitionCINV CommercialInvoice Document is an invoice.

CMCN CommercialContract Document is an agreement between the parties, stipulating the terms and conditions of the delivery of goods or services.

CNFA CreditNoteRelatedToFinancialAdjustment

Document is a credit note for the final amount settled for a commercial transaction.

CREN CreditNote Document is a credit note.

DEBN DebitNote Document is a debit note.

DNFA DebitNoteRelatedToFinancialAdjustment

Document is a debit note for the final amount settled for a commercial transaction.

FXDR ForeignExchangeDealReference

Document is a pre-agreed or pre-arranged foreign exchange transaction to which the payment transaction refers.

HIRI HireInvoice Document is an invoice for the hiring of human resources or renting goods or equipment.

MSIN MeteredServiceInvoice Document is an invoice claiming payment for the supply of metered services, eg, gas or electricity, supplied to a fixed meter.

RADM RemittanceAdviceMessage Document is a remittance advice sent separately from the current transaction.



Page 35

Code Name DefinitionRPIN RelatedPaymentInstruction Document is a linked payment instruction to which the

current payment instruction is related, eg, in a cover scenario.

SBIN SelfBilledInvoice Document is an invoice issued by the debtor.

SOAC StatementOfAccount Document is a statement of the transactions posted to the debtor's account at the supplier.

4.5 ReferredDocumentRelatedDate <RfrdDocRltdDt>Presence: [0..1]Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate

4.6 ReferredDocumentAmount <RfrdDocAmt>Presence: [0..n]Definition: Amount of money and currency of a document referred to in the remittance section. The amount is typically

either the original amount due and payable, or the amount actually remitted for the referred document.Type: This message item is composed of one of the following ReferredDocumentAmount1Choice element(s):


4.7 {Or DuePayableAmount <DuePyblAmt> [1..1] Amount




4.11 Or} TaxAmount <TaxAmt> [1..1] Amount

4.7 DuePayableAmount <DuePyblAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount specified is the exact amount due and payable to the creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.8 DiscountAppliedAmount <DscntApldAmt>Presence: [1..1]



Page 36

This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount of money resulting from the application of an agreed discount to the amount due and payable to the

creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.9 RemittedAmount <RmtdAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount of money remitted for the referred document.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.10 CreditNoteAmount <CdtNoteAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.Definition: Amount specified for the referred document is the amount of a credit note.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.11 TaxAmount <TaxAmt>Presence: [1..1]This message item is part of choice 4.6 ReferredDocumentAmount.



Page 37

Definition: Quantity of cash resulting from the calculation of the tax.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.12 DocumentReferenceNumber <DocRefNb>Presence: [0..1]Definition: Unique and unambiguous identification of a document that distinguishes that document from another

document referred to in the remittance information, usually assigned by the originator of the referred document/transaction.


minLength: 1

4.13 CreditorReference <CdtrRef>Presence: [0..1]Definition: Unique and unambiguous reference assigned by the creditor to refer to the payment transaction.

Usage: if available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the cash.

If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.


minLength: 1

4.14 Invoicer <Invcr>Presence: [0..1]Definition: Identification of the organization issuing the invoice when different than the creditor or final party Type: This message item is composed of the following PartyIdentification1 element(s):

Or Message Item <XML Tag> Mult. Represent./Type

Name <Nm> [0..1] Text

PostalAddress <PstlAdr> [0..1]

Identification <Id> [0..1]

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



Page 38

4.15 Invoicee <Invcee>Presence: [0..1]Definition: Identification of the party to whom an invoice is issued, when different than the originator or debtor.Type: This message item is composed of the following PartyIdentification1 element(s):






4.16 Debtor <Dbtr>Presence: [0..1]Definition: Debtor or Ordering customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):






4.17 DebtorAccount <DbtrAcct>Presence: [0..1]Definition: Debtor account or Ordering customer account.Type: This message item is composed of the following CashAccount3 element(s):



Type <Tp> [0 ..1] Code

Currency <Ccy> [0..1] Code


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

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



Page 39


FinancialInstitutionIdentification <FinInstnId> [1..1]

BranchIdentification <BrnchId> [0..1]

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

4.19 Amount <Amt>Presence: [0..1]Definition: Instructed amount of the payment instruction (Field 33B)Type: This message item is composed of one of the following AmountType1Choice element(s):


4.20 {Or InstructedAmount <InstdAmt> [1..1] Amount

4.21 Or} EquivalentAmount <EqvtAmt> [1..1]

4.20 InstructedAmount <InstdAmt>Presence: [1..1]This message item is part of choice 4.19 Amount.Definition: Amount of money to be transferred between debtor and creditor, before deduction of charges, expressed in

the currency of the debtor's account or in another currency..

Usage : Currency of the amount is expressed in the currency (or one of the currencies) of the debtor's account or another currency, eg, pay 1000000 EUR (and debtor's account is is EUR) or pay 1000000 JPY (and debtor's account is in EUR).

Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.21 EquivalentAmount <EqvtAmt>Presence: [1..1]This message item is part of choice 4.19 Amount.Definition: Amount of money to be transferred between the debtor and creditor, before deduction of charges, expressed

in the currency of the debtor's account, and to be transferred into a different currency.



Page 40

Usage : Currency of the amount is expressed in the currency of the debtor's account, but the amount to be transferred is in another currency. The first agent will convert the amount and currency to the to be transferred amount and currency, eg, 'pay equivalent of 100000 EUR in JPY'(and account is in EUR).

Type: This message item is composed of the following EquivalentAmount element(s):


4.22 Amount <Amt> [1..1] Amount

4.23 CurrencyOfTransfer <CcyOfTrf> [1..1] Code

4.22 Amount <Amt>Presence: [1..1]Definition: Amount of money to be transferred between debtor and creditor, before deduction of charges, expressed in

the currency of the debtor's account, and to be transferred in a different currency.

Usage : Currency of the amount is expressed in the currency of the debtor's account, but the amount to be transferred is in another currency. The first agent will convert the amount and currency to the to be transferred amount and currency, eg, 'pay equivalent of 100000 EUR in JPY'(and account is in EUR).




4.23 CurrencyOfTransfer <CcyOfTrf>Presence: [1..1]Definition: Specifies the currency of the to be transferred amount, which is different from the currency of the debtor's

account.Data Type: CurrencyCodeFormat: [A-Z]{3,3}Rule(s): ValidationByTable

4.24 NostroVostroAccount <NstrVstrAcct>Presence: [0..1]Definition: Indicates the account used to cover a payment.Type: This message item is composed of the following CashAccount3 element(s):






Page 41





4.25 Intermediary <Intrmy>Presence: [0..1]Definition: Intermediary bank.Type: This message item is composed of the following Intermediary1 element(s):



Account <Acct> [0..1]

Role <Role> [0..1] Text

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

4.26 FirstSettlementAgent <FrstSttlmAgt>Presence: [0..1]Definition: Correspondent of the first agent (Field 53 in MT202).Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):





4.27 LastSettlementAgent <LastSttlmAgt>Presence: [0..1]Definition: Correspondent of the Final agent (Field 54 of Mt 202)Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):







Page 42

4.28 IntermediarySettlementAgent <IntrmySttlmAgt>Presence: [0..1]Definition: Equivalent to Field 55 in MT202.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):





4.29 Creditor <Cdtr>Presence: [0..1]Definition: Creditor or Beneficiary customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):






4.30 CreditorAccount <CdtrAcct>Presence: [0..1]Definition: Creditor account or Beneficiary customer account.Type: This message item is composed of the following CashAccount3 element(s):







4.31 SenderToReceiverInformation <SndrToRcvrInf>Presence: [0..6]Definition: Unformatted information from the sender to the receiver.Data Type: Max35Text



Page 43

Format: maxLength: 35minLength: 1

Business Example

The following illustrates one scenario for the AdditionalPaymentInformation workflow. This scenario is based on an initial RequestToModifyPayment scenario. The AdditionalPaymentInformation message is shown in Step 3.1 below. The scenario is based on the payment characteristics in the table below.

Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.

Characteristics of the payment instruction are as follows:

Description Value

Sender Customer A (BEI CUSAGB2L)

Receiver Bank A, London (AAAAGB2L)

Instruction Reference CPAY0123456789

Transaction Reference 20050127003

Requested Execution Date 2005-01-27

Instructed Amount and Currency

52317.48 GBP

Unstructured Remittance Information

/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/

Final Agent Bank K, London (KKKKGB2L)

Creditor Customer S (ASUPGB2L)All Supplies and Co

Scenario 1, resulting in an AdditionalPaymentInformation message

NarrativeCustomer A checks its accounts payables. The dates for the two invoices have been incorrectly reported in the remittance information.

Step 1Customer A decides to request the modification of the payment instruction in order for the creditor to automatically reconcile the accounts receivables with the payment instruction amount. Customer A makes a request for modification of the payment instruction to change the remittance information content.

The following RequestToModifyPayment message is sent by Customer A to Bank A:XML Instance

<camt.007.002.01><Assgnmt>

<Id>CUSTA20050003</Id><Assgnr>CUASGB2L</Assgnr>



Page 44

<Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>

</Assgnmt><Case>

<Id>CUSTA20050003</Id><Cretr>CUSAGB2L</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>CPAY0123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Mod>

<RmtInf><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>

</RmtInf></Mod>

</camt.007.002.01>

Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to forward the RequestToModifyPayment message to Bank K (Step 2.1). At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).

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

The following RequestToModifyPayment message is sent by Bank A to Bank K:XML Instance


<Id>C103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>



Page 45

Step 2.2 Bank A informs Customer A of the case assignment to Bank K.

The following NotificationOfAssignment message is sent by Bank A to Customer A: XML Instance

<camt.030.001.01><Hdr>

<Id>RCUSTA20050001</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:50:22</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>

<Justfn>MODI</Justfn></Ntfctn>

</camt.030.001.01>

Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer S and the customer has been informed. Bank K forwards the correct remittance information content to Customer S, using an AdditionalPaymentInformation message (Step 3.1). At the same time, as there is no further processing needed, a ResolutionOfInvestigation message is sent to Bank A, notifying that the information has been delivered to the customer (Step 3.2). Bank A in turn reverts to Customer A with a ResolutionOfInvestigation message (Step 3.3).

Step 3.1Bank K forwards additional information about the payment to Customer S.

The following AdditionalPaymentInformation message is sent by Bank K to Customer S:XML Instance


<Id>I103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:52:30</CreDtTm>

</Assgnmt><Case>




Page 46

</Case><Undrlyg>

<AssgnrInstrId>I1030123456789</AssgnrInstrId></Undrlyg><Inf>

<RmtChc><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>

</RmtChc><Cdtr>

<Nm>All Supplies and Co</Nm><Id>

<OrgId><BEI>CUSBGB2L</BEI>

</OrgId></Id>

</Cdtr></Inf>

</camt.028.001.01>

Step 3.2Bank K informs Bank A of the resolution of the investigation.

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


<Id>RKKKKAAAA20050127004</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:08:23</CreDtTm>

</Assgnmt><RslvdCase>


</RslvdCase><Sts>

<Conf>MODI</Conf></Sts>

</camt.029.001.01>

Step 3.3Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.

The following ResolutionOfInvestigation message is sent by Bank A to Customer A:XML Instance


<Id>RAAAACUSA20050127004</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne>



Page 47

<CreDtTm>2005-01-27T09:18:23</CreDtTm></Assgnmt><RslvdCase>


</RslvdCase><Sts>


</camt.029.001.01>



Page 48

Message: CancelCaseAssignment <camt.032.001.01>Message Scope and UsageScopeThe CancelCaseAssignment message is sent by a case creator/case assigner to a case assignee.This message is used to request the cancellation of a case.

Usage

The CancelCaseAssignment message is used to stop the processing of a case at a case assignee when a case assignment is incorrect or when the root cause for the case disappears (eg, the account owner was able to reconcile after sending a ClaimNonReceipt message).

The CancelCaseAssignment message can be used to stop the processing of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case

The CancelCaseAssignment message covers one and only one case at a time. If several case assignments need to be cancelled, then multiple CancelCaseAssignment messages must be sent.

The CancelCaseAssignment message must be forwarded by all subsequent case assignee(s) in the case processing chain until it reaches the case creator. When the CancelCaseAssignment message is assigned to a subsequent case assignee, a NotificationOfCaseAssignment message is sent to the case assigner/case creator, in reply. When the CancelCaseAssignment instruction has been acted upon by the relevant case assignee, a ResolutionOfInvestigation message is sent to the case assigner/case creator, in reply.

The CancelCaseAssignment message must not be used for other purposes. If, for example, a request to modify payment fails, and the case creator requests the cancellation of the payment, then a RequestToCancelPayment message must be used, with the case identification of the original RequestToModifyPayment message. The CancelCaseAssignment message is not an option.

OutlineThe CancelCaseAssignment message is composed of two building blocks:



Message Structure


Message: CancelCaseAssignment <camt.032.001.01>

Page 49


Rule/ Guid.







Rule/ Guid.





Message Items DescriptionThe following section identifies the elements of the CancelCaseAssignment message.

1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1



Page 50








1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Date and time at which the assignment was created.Data Type: ISODateTime









Page 51









Business Example

The following illustrates the CancelCaseAssignment message.

Customer E (BEI EEEEUS33) instructed Bank N, New York (NNNNS33) to execute a payment. The payment settles an invoice received from Customer V (BEI VVVVUS33).


Description Value

Sender Customer E (BEI EEEEUS33)

Receiver Bank N, New York (NNNNUS33)

Instruction Reference CECOMSUP001003



Instructed Amount 10234.56 USD

Final Agent Bank F (FFFFUS33)

Creditor Customer V (VVVVUS33)



Page 52

General Plumbing and Co

NarrativeCustomer E checks its accounts payables. The payment instruction contained an incorrect amount (the payment was made for an amount excluding VAT). As the amount to be paid is higher than the amount instructed, and for ease of reconciliation, Customer E requests the cancellation of the original payment instruction and issues a new payment instruction.The new payment instruction is not illustrated in this business example.

Step 1Customer E sends a request for the cancellation of the payment instruction to Bank N, New York.

The following RequestToCancelPayment message is sent by Customer E to Bank N:XML Instance


<Id>AB20050417CANC</Id><Assgnr>EEEEUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-26T09:10:30</CreDtTm>

</Assgnmt><Case>

<Id>EEEE20050525001</Id><Cretr>EEEEUS33</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>CECOMSUP001003</AssgnrInstrId><CcyAmt Ccy = "USD">10234.56</CcyAmt><ValDt>2005-05-25T00:00:00</ValDt>

</Undrlyg><Justfn>

<CxlRsn>CUST</CxlRsn></Justfn>

</camt.008.002.01>

Step 2Bank N receives the RequestToCancelPayment message from Customer E and investigates the status of the payment instruction. The payment instruction has been correctly executed and forwarded to Bank F under reference AFFFFUS4567. Bank N forwards the RequestToCancelPayment message to Bank F (Step 2.1) and informs Customer E about the case assignment (Step 2.2).

Step 2.1 Bank N forwards the RequestToCancelPayment message to Bank F.

The following RequestToCancelPayment message is sent by Bank N to Bank F:XML Instance


<Id>NNNNCANC0001200888</Id><Assgnr>NNNNUS33</Assgnr>



Page 53

<Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-26T10:07:23</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>AFFFFUS4567</AssgnrInstrId><CcyAmt Ccy = "USD">10234.56</CcyAmt><ValDt>2005-05-25T00:00:00</ValDt>

</Undrlyg><Justfn>

<CxlRsn>CUST</CxlRsn></Justfn>

</camt.008.002.01>

Step 2.2 Bank N notifies the case assignment to Customer E.

The following NotificationOfCaseAssignment message is sent by Bank N to Customer E:XML Instance

<camt.030.001.01><Hdr>

<Id>RESPAB20050417CANC</Id><Fr>NNNNUS33</Fr><To>EEEEUS33</To><CreDtTm>2005-05-26T10:22:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>NNNNCANC0001200888</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-26T10:07:23</CreDtTm>

</Assgnmt><Ntfctn>

<Justfn>CANC</Justfn></Ntfctn>

</camt.030.001.01>

Step 3In the meantime, Bank F, New York, receives the original payment instruction. However, the account number for the beneficiary customer is not present in the message. The payment processing rules at Bank F means that a return of the payment instruction is automatically generated, together with a reason code set to account number missing (this step is not illustrated here). Customer V holds an account with Bank G and not with Bank F, New York.



Page 54

When Customer E receives its statement, it reconciles the credit entry to its account (due to the return of funds) and the pending request to cancel the payment case.The cancellation of the original payment instruction is therefore no longer necessary and Customer E decides to request the cancellation of the case assignment (Step 3.1). In turn, Bank N will request the cancellation of the assignment to Bank F, New York (Step 3.2).

Step 3.1Customer E requests the cancellation of the case assignment to Bank N.

The following CancelCaseAssignment message is sent by Customer E to Bank N:XML Instance


<Id>CANCEEEE20050525001</Id><Assgnr>EEEEUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-27T08:42:34</CreDtTm>

</Assgnmt><Case>


</Case></camt.032.001.01>

Step 3.2Bank N forwards the CancelCaseAssignment message to Bank F (Step 3.2.1) and informs Customer E of the case assignment (Step 3.2.2).

Step 3.2.1The following CancelCaseAssignment message is sent by Bank N to Bank F:XLM Instance


<Id>CANCNNNN20050527004</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-27T09:07:35</CreDtTm>

</Assgnmt><Case>


</Case></camt.032.001.01>

Step 3.2.2The following NotificationOfCaseAssignment message is sent by Bank N to Customer E:XML Instance

<camt.030.001.01><Hdr>

<Id>RCANCEEEE20050525001</Id><Fr>NNNNUS33</Fr>



Page 55

<To>EEEEUS33</To><CreDtTm>2005-05-27T10:21:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>CANCNNNN20050527004</Id><Assgnr>NNNNUS33</Assgnr><Assgne>FFFFUS33</Assgne><CreDtTm>2005-05-27T09:07:35</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Bank F, New York looks up the original instruction. The payment instruction has been returned. The case assignment can be cancelled and Bank F send a ResolutionOfInvestigation message to Bank N (its case assigner)(Step 4.1). Bank N informs Customer E, using the same message (Step 4.2).

Step 4.1The following ResolutionOfInvestigation message is sent by Bank F to Bank N:XML Instance


<Id>CONFCONFCANC20050527004</Id><Assgnr>FFFFUS33</Assgnr><Assgne>NNNNUS33</Assgne><CreDtTm>2005-05-27T10:27:21</CreDtTm>



</RslvdCase><Sts>

<Conf>CNCL</Conf></Sts>

</camt.029.001.01>

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


<Id>CONCANCEEEE20050525001</Id>



Page 56

<Assgnr>NNNNUS33</Assgnr><Assgne>EEEEUS33</Assgne><CreDtTm>2005-05-27T12:54:22</CreDtTm>



</RslvdCase><Sts>

<Conf>CANC</Conf></Sts>

</camt.029.001.01>



Page 57

Message: CaseStatusReport <camt.039.001.01>Message Scope and UsageScopeThe CaseStatusReport message is sent by a case assignee to a case creator/case assigner.

This message is used to report on the status of a case.

Usage

A CaseStatusReport message is sent in reply to a CaseStatusReportRequest message.

The CaseStatusReport message covers one and only one case at a time. If a case assignee needs to report on several cases, then multiple CaseStatusReport messages must be sent.

The CaseStatusReport message may be forwarded to subsequent case assigner(s) until it reaches the case creator.

The CaseStatusReport message allows to indicate a case assignment to a subsequent case assignee.

The CaseStatusReport message must not be used in place of a ResolutionOfInvestigation or NotificationOfCaseAssignment message.

OutlineThe CaseStatusReport message is composed of four building blocks:

A.Report HeaderThis building block is mandatory.


C.Case StatusThis building block is mandatory.

D.New AssignmentThis building block is optional.

Message Structure


Rule/ Guid.

No.1.0 Header <Hdr> [1..1]


Message: CaseStatusReport <camt.039.001.01>

Page 58


Rule/ Guid.

No.1.1 Identification <Id> [1..1] Text

1.2 From <Fr> [1..1] Identifier

1.3 To <To> [1..1] Identifier



Rule/ Guid.






Rule/ Guid.

No.3.0 Status <Sts> [1..1]

3.1 DateTime <DtTm> [1..1] DateTime

3.2 CaseStatus <CaseSts> [1..1] Code

3.3 InvestigationStatus <InvstgtnSts> [0..1] Code

3.4 Reason <Rsn> [0..1] Text


Rule/ Guid.

No.4.0 NewAssignment <NewAssgnmt> [0..1]





Message Items DescriptionThe following section identifies the elements of the CaseStatusReport message.



Page 59

1.0 Header <Hdr>Presence: [1..1]Definition: Specifies generic information about an investigation report.Type: The Header block is composed of the following ReportHeader element(s):






1.1 Identification <Id>Presence: [1..1]Definition: Identification of the report.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule


1.3 To <To>Presence: [1..1]Definition: Party to which the status of the case is reported.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule


1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.



Page 60
















3.0 Status <Sts>Presence: [1..1]



Page 61

Definition: Defines the status of the case.Type: The Status block is composed of the following CaseStatus element(s):


3.1 DateTime <DtTm> [1..1] DateTime

3.2 CaseStatus <CaseSts> [1..1] Code

3.3 InvestigationStatus <InvstgtnSts> [0..1] Code


3.1 DateTime <DtTm>Presence: [1..1]Definition: Date and time of the status.Data Type: ISODateTime

3.2 CaseStatus <CaseSts>Presence: [1..1]Definition: Status of the case.Data Type: CodeOne of the following CaseStatus1Code values must be used:

Code Name DefinitionASGN Assigned Case has been assigned to another party.

CLOSE Closed Case has been closed.

INVE UnderInvestigation Case is currently under investigation.

UKNW Unknown Case has never been assigned before.

3.3 InvestigationStatus <InvstgtnSts>Presence: [0..1]Definition: Status of the investigation.Data Type: CodeWhen this message item is present, one of the following InvestigationExecutionConfirmation1Code values must be used:

Code Name DefinitionACDA AcceptedDebitAuthorisation Returned when a creditor accepts the debit authorisation.

CNCL CancelledAsPerRequest Returned when a requested cancellation is successfull.

CONF ConfirmationOfPayment Returned when a payment has been checked and was correctly executed.

CWFW CancellationWillFollow Returned when a payment will be cancelled to solve an investigation case.

ICOV CoverInitiated Returned when a transfer of funds has been initiated (a cover payment) to resolve a case.



Page 62

Code Name DefinitionINFO AdditionalInformationSent Returned when additional information has been sent to the

beneficiary of a payment.

IPAY PaymentInitiated Returned when the result of an investigation is the initiation of payment instruction.

IPYI PaymentInstructionInitiated Returned when a payment instruction (eg. MT103) has been initiated to resolve a case.

MCOV CoverModified Returned when a transfer of funds has been modified (a cover payment) to resolve a case.

MODI ModifiedAsPerRequest Returned when a requested modification is successfull.

3.4 Reason <Rsn>Presence: [0..1]Definition: Free text justification of the status.Data Type: Max140TextFormat: maxLength: 140

minLength: 1

4.0 NewAssignment <NewAssgnmt>Presence: [0..1]Definition: Identifies the last assignment performed.Type: The NewAssignment block is composed of the following CaseAssignment element(s):







minLength: 1


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



Page 63

Rule(s): AnyBICRule Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.






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.


Description Value

Sender Customer G (BEI CUSGHKHH)

Receiver Bank G, Hong Kong (GGGGHKHH)

Instruction Reference GCOMPAY0123456789



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

NarrativeOn 27 May 2005, Customer G checks its accounts payables. A wrong amount has been paid to settle the invoice. As the execution date is not reached yet, Customer G requests the modification of the amount to be paid for the invoice.

Step 1Customer G requests the modification of the amount of the payment instruction (the amount should be 1331387.40 HKD instead of 1267988.00 HKD).

The following RequestToModifyPayment message is sent by Customer G to Bank G, Hong Kong:XML Instance


<Id>CUSGHKHHMODGCOMPAY0123456789</Id><Assgnr>CUSGHKHH</Assgnr><Assgne>GGGGHKHH</Assgne><CreDtTm>2005-05-27T10:18:56</CreDtTm>

</Assgnmt><Case>

<Id>CUSGMOD050527001</Id><Cretr>CUSGHKHH</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>GCOMPAY0123456789</AssgnrInstrId><CcyAmt Ccy="HKD">1267988.00</CcyAmt><ValDt>2005-05-29T00:00:00</ValDt>

</Undrlyg><Mod>

<IntrBkSttldAmt Ccy="HKD">1331387.40</IntrBkSttldAmt></Mod>

</camt.007.002.01>

Step 2On 28 May 2005, Customer G has not yet received a response from Bank G on the RequestToModifyPayment message and requests a report of the status of the case, as the requested execution date is set for the next day.

The following CaseStatusReportRequest message is sent by Customer G to Bank G:XML Instance

<camt.038.001.01><ReqHdr>

<Id>CSRRCUSGMOD050527001</Id><Fr>CUSGHKHH</Fr><To>GGGGHKHH</To><CreDtTm>2005-05-28T10:35:30</CreDtTm>

</ReqHdr><Case>


</Case></camt.038.001.01>



Page 65

Step 3Bank G looks up the original case and assesses the status. The modification requested has been made on 27 May 2005, following the RequestToModifyPayment message and the case can be closed.

The following CaseStatusReport message is sent by Bank G to Customer G:XML Instance

<camt.039.001.01><Hdr>

<Id>HSBCRCSRRCUSGMOD050527001</Id><Fr>GGGGHKHH</Fr><To>CUSGHKHH</To><CreDtTm>2005-05-28T10:44:12</CreDtTm>

</Hdr><Case>


</Case><Sts>

<DtTm>2005-05-27T10:23:43</DtTm><CaseSts>CLOSE</CaseSts><InvstgtnSts>MODI</InvstgtnSts>

</Sts></camt.039.001.01>



Page 66

Message: CaseStatusReportRequest <camt.038.001.01>Message Scope and UsageScopeThe CaseStatusReportRequest message is sent by a case creator/case assigner to a case assignee.

This message is used to request the status of a case.

Usage

The CaseStatusReportRequest message must be answered with a CaseStatusReport message.

The CaseStatusReportRequest message can be used to request the status of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case

The CaseStatusReportRequest message covers one and only one case at a time. If a case creator/case assigner needs the status of several cases, then multiple CaseStatusReportRequest messages must be sent.

The CaseStatusReportRequest may be forwarded to subsequent case assignee(s) in the case processing chain.

The processing of a case generates NotificationOfCaseAssignment and/or ResolutionOfInvestigation messages to the case creator/case assigner. The CaseStatusReportRequest must therefore only be used when no information has been received from the case assignee within the expected time frame.

OutlineThe CaseStatusReportRequest message is composed of two building blocks:

A.Report HeaderThis building block is mandatory.


Message Structure


Rule/ Guid.

No.1.0 RequestHeader <ReqHdr> [1..1]



Message: CaseStatusReportRequest <camt.038.001.01>

Page 67


Rule/ Guid.

No.1.2 From <Fr> [1..1] Identifier




Rule/ Guid.





Message Items DescriptionThe following section identifies the elements of the CaseStatusReportRequest message.

1.0 RequestHeader <ReqHdr>Presence: [1..1]Definition: Identifies the party requesting the status, the requested party, the identification and the date of the status.Type: The RequestHeader block is composed of the following ReportHeader element(s):







minLength: 1

1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifier



Page 68

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




1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.Data Type: ISODateTime









2.2 Creator <Cretr>Presence: [1..1]



Page 69

Definition: Party that created the case.






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.


Description Value

Sender Customer G (BEI CUSGHKHH)

Receiver Bank G, Hong Kong (GGGGHKHH)

Instruction Reference GCOMPAY0123456789



Instructed Amount and Currency 1267988.00 HKD

Unstructured Remittance Information /INV/20050502/HKD1267988,/200505030233/

Final Agent Bank K, Hong Kong (KKKKHKHH)

Creditor Customer H (BEI HSFIHKHH)Han and Sons Fisheries

NarrativeOn 27 May 2005, Customer G checks its accounts payables. A wrong amount has been paid to settle the invoice. As the execution date is not reached yet, Customer G requests the modification of the amount to be paid for the invoice.



Page 70

Step 1Customer G requests the modification of the amount of the payment instruction (the amount should be 1331387.40 HKD instead of 1267988.00 HKD).

The following RequestToModifyPayment message is sent by Customer G to Bank G, Hong Kong:XML Instance


<Id>CUSGHKHHMODGCOMPAY0123456789</Id><Assgnr>CUSGHKHH</Assgnr><Assgne>GGGGHKHH</Assgne><CreDtTm>2005-05-27T10:18:56</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>GCOMPAY0123456789</AssgnrInstrId><CcyAmt Ccy="HKD">1267988.00</CcyAmt><ValDt>2005-05-29T00:00:00</ValDt>

</Undrlyg><Mod>

<IntrBkSttldAmt Ccy="HKD">1331387.40</IntrBkSttldAmt></Mod>

</camt.007.002.01>

Step 2On 28 May 2005, Customer G has not yet received a response from Bank G on the RequestToModifyPayment message and requests a report of the status of the case, as the requested execution date is set for the next day.

The following CaseStatusReportRequest message is sent by Customer G to Bank G:XML Instance

<camt.038.001.01><ReqHdr>

<Id>CSRRCUSGMOD050527001</Id><Fr>CUSGHKHH</Fr><To>GGGGHKHH</To><CreDtTm>2005-05-28T10:35:30</CreDtTm>

</ReqHdr><Case>


</Case></camt.038.001.01>

Step 3Bank G looks up the original case and assesses the status. The modification requested has been made on 27 May 2005, following the RequestToModifyPayment message and the case can be closed.



Page 71

The following CaseStatusReport message is sent by Bank G to Customer G:XML Instance

<camt.039.001.01><Hdr>

<Id>HSBCRCSRRCUSGMOD050527001</Id><Fr>GGGGHKHH</Fr><To>CUSGHKHH</To><CreDtTm>2005-05-28T10:44:12</CreDtTm>

</Hdr><Case>


</Case><Sts>

<DtTm>2005-05-27T10:23:43</DtTm><CaseSts>CLOSE</CaseSts><InvstgtnSts>MODI</InvstgtnSts>

</Sts></camt.039.001.01>



Page 72

Message: ClaimNonReceipt <camt.027.001.01>Message Scope and UsageScopeThe ClaimNonReceipt message is sent by a case creator/case assigner to a case assignee.

This message is used to initiate an investigation for missing funds at the creditor (missing credit entry to its account) or at an agent along the processing chain (missing cover for a received payment instruction).

Usage

The claim non receipt case occurs in two situations:- the creditor is expecting funds from a particular debtor and cannot find the corresponding credit entry on its account.

In this situation, it is understood that the creditor will contact its debtor, and that the debtor will trigger the claim non receipt case on its behalf. A workflow where the creditor directly addresses a ClaimNonReceipt message to its account servicing institution is not retained.

- an agent in the processing chain cannot find a cover payment corresponding to the information in a received payment instruction. In this missing cover situation, the agent may directly trigger the investigation by sending a ClaimNonReceipt message to the sender of the original payment instruction.

The ClaimNonReceipt message covers one and only one payment instruction at a time. If several expected payment instructions/cover instructions are found missing, then multiple ClaimNonReceipt messages must be sent.Depending on the result of the analysis of the original payment instruction processing by a case assignee (incorrect routing, errors/omissions when processing the instruction, or no error) and the processing stage of the payment instruction, the claim non receipt case may be viewed as a: - RequestToCancelPayment message, sent to the subsequent agent in the payment processing chain, if the original

payment instruction has been incorrectly routed through the chain of agents. (This also entails that a new corrected payment instruction is issued).

- RequestToModifyPayment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction.

In the cover is missing, the case assignee may also simply issue the omitted cover payment. The case assignee will issue a ResolutionOfInvestigation message with the CorrectionTransaction element mentioning the references of the cover payment.

The ClaimNonReceipt message may be forwarded to subsequent case assignees.

Main characteristicsThe ClaimNonReceipt message has the following main characteristics:

Case IdentificationThe case creator assigns a unique case identification. This information will be passed unchanged to subsequent case assignee(s).

Underlying Payment Instruction IdentificationThe case creator refers to the identification of the underlying payment instruction. This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s).


Message: ClaimNonReceipt <camt.027.001.01>

Page 73

MissingCoverIndicationThe MissingCoverIndication element distinguishes between a missing cover situation (when set to yes) or a missing funds situation (when set to no).

OutlineThe ClaimNonReceipt message is composed of four building blocks:



C. Payment Instruction ExtractThis building block is mandatory.

D. Missing Cover IndicatorThis building block is optional.

Message Structure


Rule/ Guid.







Rule/ Guid.







Page 74


Rule/ Guid.







Rule/ Guid.

No.4.0 MissingCover <MssngCover> [0..1]

4.1 MissingCoverIndication <MssngCoverIndctn> [1..1] Indicator

Message Items DescriptionThe following section identifies the elements of the ClaimNonReceipt message.

1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies an assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1




Page 75








2.0 Case <Case>Presence: [1..1]Definition: Identifies a case.Type: The Case block is composed of the following Case element(s):







minLength: 1Example:



Page 76

<Id>Case001</Id>







3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the payment instruction for which the Creditor has not received the funds.

Note: In case of a missing cover, it must be the Field 20 of the received MT103.In case of a claim non receipt initiated by the Debtor, it must be the identification of the instruction (Field 20 of MT103, Instruction Identification of the Payment Initiation or the Bulk Credit Transfer).

Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):







minLength: 1



Page 77


minLength: 1






4.0 MissingCover <MssngCover>Presence: [0..1]Definition: Indicates if the claim non receipt is a missing cover. The absence of the component means that the message

is not for a missing cover. Type: The MissingCover block is composed of the following MissingCover element(s):


4.1 MissingCoverIndication <MssngCoverIndctn> [1..1] Indicator

4.1 MissingCoverIndication <MssngCoverIndctn>Presence: [1..1]Definition: Indicates if the message is relative to a missing cover. Data Type: One of the following YesNoIndicator values must be used:




Page 78

Business Example

The following illustrates four scenarios for the ClaimNonReceipt workflow.

Narrative for Scenarios 1, 2 and 3

Customer A (BEI AAAAFRPP) regularly orders goods from Customer V (BEI VVVVGB2L). Customer A settles its invoices on a monthly basis.

On 6 June 2005, Customer V calls Customer A to enquire about the payment for May 2005. After investigation, it appears that Customer A indeed requested payment to its bank (FFFFFRPP). Customer A issues a claim for non receipt investigation to Bank F on behalf of Customer V.


Description Value

Sender Customer A, Paris (BEI AAAAFRPP)

Receiver Bank F, Paris (FFFFFRPP)

Instruction Reference 0505PAY09876543



Instructed Amount 13498.52 GBP

Unstructured Remittance Information /INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/

Final Agent Bank U, London (UUUUGB2L)

Creditor Customer V (BEI VVVVGB2L)Country Fragrances plc

Scenario 1, resulting in a RequestToCancelPayment messageThe steps illustrated below are limited to the ClaimNonReceipt workflow. Details for the request for debit authorisation and debit authorisation response appear in the RequestToCancelPayment workflow.

Step 1The following ClaimNonReceipt message is sent by Customer A to Bank F:XML Instance


<Id>CNRVVVVGB2L200506020001</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-06T10:35:23</CreDtTm>

</Assgnmt><Case>

<Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>



Page 79

</Case><Undrlyg>

<AssgnrInstrId>0505PAY09876543</AssgnrInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>

</Undrlyg></camt.027.001.01>

Step 2Bank F looks up the original payment instruction. It has been executed correctly and sent to Bank U under reference 345601234. Bank F forwards the claim for non receipt investigation to Bank U, London for further investigation (Step 2.1). At the same time Bank F informs Customer A of the case assignment to Bank U (Step 2.2).

Step 2.1Bank F forwards the claim for non receipt to Bank U, London.

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


<Id>CNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-06T10:45:21</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>345601234</AssgnrInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>

</Undrlyg></camt.027.001.01>

Step 2.2Bank F informs Customer A of the case assignment to Bank U, London.

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

<camt.030.001.01><Hdr>

<Id>REPCNR0505PAY09876543</Id><Fr>FFFFFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-06-06T10:52:59</CreDtTm>

</Hdr><Case>




Page 80

</Case><Assgnmt>

<Id>CNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-06T10:45:21</CreDtTm>

</Assgnmt><Ntfctn>

<Justfn>FTHI</Justfn></Ntfctn>

</camt.030.001.01>

Step 3Bank U looks up the original instruction. The funds have been wrongly credited to another customer's account (Customer Z). Bank U requests and obtains a debit authorisation from Customer Z and makes the entry with back value on the account of Customer V. The case is closed and Bank U informs Bank F that the investigation is resolved (Step 3.1). Upon receipt, Bank F informs Customer A of the case resolution (Step 3.2)

Step 3.1Bank U, London informs Bank F that the investigation is resolved.

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


<Id>CLOSECNR200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T11:32:57</CreDtTm>



</RslvdCase><Sts>

<Conf>CONF</Conf></Sts>

</camt.029.001.01>

Step 3.2Bank F informs Customer A of the successful case resolution.

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


<Id>CLOSECNRVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T11:45:17</CreDtTm>

</Assgnmt>



Page 81

<RslvdCase><Id>CNR0505PAY09876543</Id><Cretr>AAAAFRPP</Cretr>

</RslvdCase><Sts>


</camt.029.001.01>

Scenario 2, resulting in an AdditionalPaymentInformation message The initial steps of this scenario (Steps 1 and 2) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 3.

Step 3Bank U, London looks up the original payment instruction and compares it against the statement delivered to Customer V. The remittance information, as well as the identity of the debtor, have not been correctly mentioned. The account owner reference attached to the entry is 20050602-;0001. Bank U decides to provide this additional payment information to Customer V.

The following AdditionalPaymentInformation message is sent by Bank U to Customer V:XML Instance


<Id>INFOVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>200506020001</AssgneInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>

</Undrlyg><Inf>

<RmtChc><Ustrd>/INV/20050516/GBP8257,43/20050500102356//20050412/GBP5241,09/20050500202356/</Ustrd>

</RmtChc><Dbtr>

<Nm>Customer A</Nm><Id>

<OrgId><BEI>AAAAFRPP</BEI>

</OrgId></Id>

</Dbtr><Cdtr>



Page 82

<Id><OrgId>

<BEI>VVVVGB2L</BEI></OrgId>

</Id></Cdtr>

</Inf></camt.028.001.01>

Step 4Customer V, based on the additional payment information from Bank U, matches the entry with its accounts receivables. Customer V informs Bank U that the investigation has been resolved (Step 4.1). Bank U forwards the message to Bank F (Step 4.2). Bank F informs Customer A of the successful case resolution (Step 4.3).

Step 4.1Customer V solves the case.

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


<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>VVVVGB2L</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-07T11:45:47</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 4.2Bank U closes the case and forwards the case resolution information to Bank F.



<Id>CLOSECNR200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T11:54:54</CreDtTm>



</RslvdCase>



Page 83

<Sts><Conf>CONF</Conf>

</Sts></camt.029.001.01>

Step 4.3Bank F closes the case and forwards the case resolution information to Customer A.



<Id>CLOSECNR200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T12:15:15</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Scenario 3, resulting in a RequestToModifyPayment messageThe initial steps of this scenario (steps 1 and 2) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 3.

Step 3Bank U looks up the original payment instruction and compares it against the statement delivered to Customer V. The remittance information is incorrect. It should read /INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/ instead of: Payment for expenses May 2005. Bank U decides to request the modification of the payment instruction from Customer V (Step 3.1). Bank U notifies Bank F of the case assignment (Step 3.2). Upon receipt, Bank F informs Customer A (Step 3.3).

Step 3.1Bank U requests the modification of the payment instruction.

The following RequestToModifyPayment message is sent by Bank U to Customer V:XML Instance


<Id>MODIVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>VVVVGB2L</Assgne><CreDtTm>2005-06-06T10:53:42</CreDtTm>

</Assgnmt><Case>



Page 84


</Case><Undrlyg>

<AssgneInstrId>200506020001</AssgneInstrId><CcyAmt Ccy = "GBP">13498.52</CcyAmt><ValDt>2005-06-01T00:00:00</ValDt>

</Undrlyg><Mod>

<RmtInf><Ustrd>/INV/20050516/GBP8257.43/20050500102356//20050412/GBP5241.09/20050500202356/</Ustrd>

</RmtInf></Mod>

</camt.007.002.01>

Step 3.2Bank U informs Bank F of the case assignment.

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

<camt.030.001.01><Hdr>

<Id>FORWFRAGB2L200506020001</Id><Fr>UUUUGB2L</Fr><To>FFFFFRPP</To><CreDtTm>2005-06-06T10:55:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3.3Bank F informs Customer A of the case assignment.

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

<camt.030.001.01><Hdr>

<Id>FF200506020001</Id><Fr>FFFFFRPP</Fr>



Page 85

<To>AAAAFRPP</To><CreDtTm>2005-06-06T11:05:25</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Based on the modification request, Customer V reconciles the entry with its accounts receivables. The case is closed. Customer V informs Bank U of the successful case resolution (Step 4.1). Upon receipt, Bank U closes the case and forwards the case resolution information to Bank F (Step 4.2). Bank F informs Customer A of the successful closure of the investigation (Step 4.3).

Step 4.1Customer V informs Bank U of the resolution of the case.

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


<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>VVVVGB2L</Assgnr><Assgne>UUUUGB2L</Assgne><CreDtTm>2005-06-07T12:05:43</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 4.2Bank U informs Bank F of the resolution of the case.




Page 86


<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>UUUUGB2L</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T12:12:03</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 4.3Bank F informs Customer A of the resolution of the case.



<Id>CLOSEVVVVGB2L200506020001</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-06-07T12:17:04</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Scenario 4, resulting in a successful case resolutionThe following illustrates the fourth scenario for the ClaimNonReceipt workflow. This specific scenario corresponds to a missing cover case, ie, an agent has received an instruction (MT 103) which cannot be reconciled with an incoming cover payment (MT 202). The resolution of the investigation below relies upon the final agent modifying the cover payment by providing the correct reconciliation key (equivalent to the related reference in the MT 202).

NarrativeBank J (JJJJJPJT) receives a payment instruction (MT 103) referenced 123456789012 from Bank F (FFFFFRPP). The instruction indicates that the cover should be provided through its euro clearing correspondent, Bank D, Frankfurt (DDDDDEFF). During the reconciliation process of statements provided by Bank D, Bank J cannot trace the cover payment.




Page 87

Description Value

Sender Bank F (FFFFFRPP)

Receiver Bank J (JJJJJPJT)

Instruction Reference 123456789012

Requested Execution Date 2005-;05-;05

Instructed Amount 2756.22 EUR

Step 1Bank J suspects that the cover for the payment instruction received was not executed and it decides to go back to the initiator of the MT 103 to enquire about the cover.The following ClaimNonReceipt message is sent by Bank J to Bank F:XML Instance


<Id>20050505COV123456789012</Id><Assgnr>JJJJJPJT</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-05-05T06:35:23</CreDtTm>

</Assgnmt><Case>

<Id>MC123456789012</Id><Cretr>JJJJJPJT</Cretr>

</Case><Undrlyg>

<AssgneInstrId>123456789012</AssgneInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>

</Undrlyg><MssngCover>

<MssngCoverIndctn>true</MssngCoverIndctn></MssngCover>

</camt.027.001.01></Document>

Step 2Bank F looks up the original instruction and the cover. Both have been executed correctly. The transaction reference number for the MT 202 is COV12345678. Bank F assigns the claim for non receipt investigation to Bank H (the next agent for the MT 202, HHHHFRPP) (Step 2.1). Bank F informs Bank J of the case assignment to Bank H (Step 2.2).

Step 2.1Bank F assigns the claim non receipt request to Bank H.

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


<Id>20050505COV12345678</Id>



Page 88

<Assgnr>FFFFFRPP</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-05-05T09:35:23</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>COV12345678</AssgneInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>

</Undrlyg></camt.027.001.01>

Step 2.2Bank F informs Bank J of the case assignment to Bank H.

The following NotificationOfCaseAssignment message is sent by Bank F to Bank J:XML Instance

<camt.030.001.01><Hdr>

<Id>INFOMC123456789012</Id><Fr>FFFFFRPP</Fr><To>JJJJJPJT</To><CreDtTm>2005-05-05T09:54:22</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>20050505COV12345678</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-05-05T09:35:23</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank H looks up the original transaction (MT 202) and finds out that it was correctly executed and forwarded to Bank D, under reference JJJJ1234567. It forwards the claim for non receipt investigation to the euro correspondent of Bank J, Bank D (Step 3.1). Bank H notifies the case assignment to Bank F (Step 3.2).

Step 3.1Bank H assigns the case to Bank D.

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



Page 89

XML Instance<camt.027.001.01>

<Assgnmt><Id>20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-05-05T09:55:23</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>JJJJ1234567</AssgnrInstrId><CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>

</Undrlyg></camt.027.001.01>

Step 3.2Bank H informs Bank F of the case assignment to Bank D.

The following NotificationOfCaseAssignment message is sent by Bank H to Bank F:XML Instance

<camt.030.001.01><Hdr>

<Id>FUMC123456789012</Id><Fr>HHHHFRPP</Fr><To>FFFFFRPP</To><CreDtTm>2005-05-05T09:59:18</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-05-05T09:55:23</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Bank D checks the instruction received from Bank H. The MT 202 has been received late and the value date for the MT 202 is set for the next day. The credit entry for the MT 202 does not have the requested value date. Bank D decides to back value the entry to the preceding day for Bank J. Although the entry will be reported on the next day statement, it will bear the correct value date. The instruction has been modified and the case is therefore closed.



Page 90

Bank D informs Bank H of the successful case resolution (Step 4.1). Bank H forwards the resolution of the case to Bank F (Step 4.2). Finally Bank F reverts to Bank J with the same information (Step 4.3).

Step 4.1Bank D informs Bank H of the successful case resolution.

The following ResolutionOfInvestigation message is sent by Bank D to Bank H:XML Instance


<Id>REP20050505COV12345678</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>HHHHFRPP</Assgne><CreDtTm>2005-06-07T12:19:05</CreDtTm>



</RslvdCase><Sts>

<Conf>MCOV</Conf></Sts><CrrctnTx>

<CcyAmt Ccy = "EUR">2756.22</CcyAmt><ValDt>2005-05-05T00:00:00</ValDt>

</CrrctnTx></camt.029.001.01>

</Document>

Scenario 4.2Bank H informs Bank F of the successful case resolution.

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


<Id>FOLL20050505COV12345678</Id><Assgnr>HHHHFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-06-07T12:22:05</CreDtTm>



</RslvdCase><Sts>





Page 91


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

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


<Id>FOLL20050505COV12345678</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>JJJJJPJT</Assgne><CreDtTm>2005-06-07T12:25:05</CreDtTm>



</RslvdCase><Sts>






Page 92

Message: DebitAuthorisationRequest <camt.037.001.01>Message Scope and UsageScopeThe DebitAuthorisationRequest message is sent by an account servicing institution to an account owner.

This message is used to request authorisation to debit an account.

Usage

The DebitAuthorisationRequest message must be answered with a DebitAuthorisationResponse message.

The DebitAuthorisationRequest message can be used to request debit authorisation in a:- request to modify payment case (lower amount or change of creditor)- request to cancel payment case (full amount)- unable to apply case (the creditor is not the intended beneficiary)- claim non receipt case (the creditor is not the intended beneficiary)

The DebitAuthorisationRequest message covers one and only one payment instruction at a time. If an account servicing institution needs to request debit authorisation for several instructions, then multiple DebitAuthorisationRequest messages must be sent.

The DebitAuthorisationRequest must be used exclusively between the account servicing institution and the account owner. It must not be used in place of a RequestToModifyPayment or RequestToCancelPayment message between subsequent agents.

OutlineThe DebitAuthorisationRequest message is composed of four building blocks:



C.Payment Instruction ExtractThis building block is mandatory.

D. Debit Authorisation DetailsThis building block is mandatory.

Message Structure


Message: DebitAuthorisationRequest <camt.037.001.01>

Page 93


Rule/ Guid.







Rule/ Guid.






Rule/ Guid.







Rule/ Guid.

No.4.0 Detail <Dtl> [1..1]

4.1 CancellationReason <CxlRsn> [1..1] Code

4.2 AmountToDebit <AmtToDbt> [0..1] Amount

4.3 ValueDateToDebit <ValDtToDbt> [0..1] DateTime

Message Items DescriptionThe following section identifies the elements of the DebitAuthorisationRequest message.



Page 94

1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the case assignment.Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1










Page 95















MeaningWhenTrue: Yes



Page 96

MeaningWhenFalse: No

3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the underlying payment instructrion.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):







minLength: 1


minLength: 1





3.4 ValueDate <ValDt>Presence: [0..1]



Page 97

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

4.0 Detail <Dtl>Presence: [1..1]Definition: Detailed information about the request.Type: The Detail block is composed of the following DebitAuthorisationDetails element(s):





4.1 CancellationReason <CxlRsn>Presence: [1..1]Definition: Indicates the reason for cancellation.Data Type: CodeOne of the following CancellationReason1Code values must be used:

Code Name DefinitionAGNT IncorrectAgent Agent in the payment workflow is incorrect.

CURR IncorrectCurrency Currency of the payment is incorrect.

CUST RequestedByCustomer Cancellation requested by the Debtor.

DUPL DuplicatePayment Payment is a duplicate of another payment.

UPAY UnduePayment Payment is not justified.

4.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount of money to be transferred between the debtor and creditor, before charges.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.



Page 98

Data Type: ISODate

Business Example

The following illustrates one scenario for the DebitAuthorisationRequest workflow. This scenario is based on an initial RequestToModifyPayment scenario. The DebitAuthorisationRequest message is shown in Step 3.1 below. The scenario is based on the payment characteristics in the table below.

Customer A (BEI CUSAGB2L) instructed Bank A (AAAAGB2L) to execute a payment. The payment settles a series of invoices received in January 2005 and referenced in the remittance information section of the payment instruction. The unstructured remittance information reproduced below refers to two commercial invoices.Characteristics of the payment instruction are as follows:

Description Value







52317.48 GBP


/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/



Scenario 1, resulting in a DebitAuthorisationRequest message

NarrativeCustomer A checks its accounts payables and receivables, and discovers a credit note of 3743.52 GBP dated 15 December 2004 under reference 20041208204712 received from Customer S that should have been deducted from the amount of the last invoice.

Step 1 Customer A makes a request for modification of the payment instruction to lower the payment amount. The new payment amount is 48573.96 GBP instead of the original amount. Within the same request for modification, Customer A supplements the remittance information in order to allow Customer S to reconcile the new amount.



<Id>CUSTA20050001</Id><Assgnr>CUASGB2L</Assgnr>



Page 99

<Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>

</Assgnmt><Case>

<Id>CUSTA20050001</Id><Cretr>CUASGB2L</Cretr>

</Case><Undrlyg>


</Undrlyg><Mod>

<IntrBkSttldAmt Ccy = "GBP">48573.96</IntrBkSttldAmt><RmtInf>

<Ustrd>/INV/20050112/GBP23257./20050100104712//20050122/GBP29060.48/20050100204712/CRE/20041215/GBP3743.52/20041208304712</Ustrd>

</RmtInf></Mod>

</camt.007.002.01>

Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has been forwarded, under reference 1030123456789 to Bank K for further processing. Bank A therefore forwards the RequestToModifyPayment message to Bank K (Step 2.1) and subsequently informs Customer A about the case assignment (Step 2.2).

Step 2.1Bank A forwards the RequestToModifyPayment message to Bank K:XML Instance


<Id>CUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>



</RmtInf>



Page 100

</Mod></camt.007.002.01>

Step 2.2Bank A informs Customer A of the case assignment to Bank K.

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

<camt.030.001.01><Hdr>

<Id>AAAACUSA20050127003</Id><Fr>AAAAGB2L</Fr><To>CUSAGB2L</To><CreDtTm>2005-01-27T08:45:30</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The credit has been passed onto the account of Customer S who has already been notified. Bank K needs to request debit authorisation from Customer S (Step 3.1) and to inform Bank A of the case assignment (Step 3.2).

Step 3.1Bank K requests debit authorisation from Customer S.

The following DebitAuthorisationRequest message is sent by Bank K to Customer S:XML Instance


<Id>103KKKKSUPPLIES1234567890</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:50:30</CreDtTm>

</Assgnmt><Case>


</Case>



Page 101

<Undrlyg><AssgnrInstrId>1030123456789</AssgnrInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Dtl>

<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy = "GBP">3743.52</AmtToDbt>

</Dtl></camt.037.001.01>

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

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

<camt.030.001.01><Hdr>

<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr><To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>

<Justfn>DTAU</Justfn></Ntfctn>

</camt.030.001.01>

Step 4Customer S responds positively to the request for debit authorisation from Bank K.

The following DebitAuthorisationResponse message is sent by Customer S to Bank K:XML Instance


<Id>REP103KKKKSUPPLIES12345678901</Id><Assgnr>ASUPGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T10:55:23</CreDtTm>

</Assgnmt><Case>

<Id>CUSTA20050001</Id>



Page 102

<Cretr>CUSAGB2L</Cretr></Case><Conf>

<DbtAuthstn>true</DbtAuthstn></Conf>

</camt.036.001.01>

Step 5Upon receipt of the positive DebitAuthorisationResponse message, Bank K debits the account of Customer S for the amount specified and returns the funds in favour of Customer A via Bank A. (This process is not illustrated here) Bank K also informs the case assigner, Bank A, about the positive case resolution.

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


<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T10:59:42</CreDtTm>



</RslvdCase><Sts>

<Conf>ACDA</Conf></Sts>

</camt.029.001.01>

Step 6Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.



<Id>RCUSTA20050001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T11:04:27</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>



Page 103

Message: DebitAuthorisationResponse <camt.036.001.01>Message Scope and UsageScopeThe DebitAuthorisationResponse message is sent by an account owner to its account servicing institution.

This message is used to approve or reject a debit authorisation request.

UsageThe DebitAuthorisationResponse message is used to reply to a DebitAuthorisationRequest message.

The DebitAuthorisationResponse message covers one and only one payment instruction at a time. If an account owner needs to reply to several DebitAuthorisationRequest messages, then multiple DebitAuthorisationResponse messages must be sent.

The DebitAuthorisationResponse message indicates whether the account owner is in agreement to the request by means of a code. It also allows further details to be given about the debit authorisation, such as acceptable amount and value date for the debit.

The DebitAuthorisationResponse message must be used exclusively between the account owner and the account servicing institution. It must not be used in place of a ResolutionOfInvestigation message between subsequent agents.

OutlineThe DebitAuthorisationResponse message is composed of three building blocks:



C.Debit Authorisation ConfirmationThis building block is mandatory.

Message Structure


Rule/ Guid.







Message: DebitAuthorisationResponse <camt.036.001.01>

Page 104


Rule/ Guid.






Rule/ Guid.

No.3.0 Confirmation <Conf> [1..1]

3.1 DebitAuthorisation <DbtAuthstn> [1..1] Indicator




Message Items DescriptionThe following section identifies the elements of the DebitAuthorisationResponse message.

1.0 Assignment <Assgnmt>Presence: [1..1]Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1



Page 105









2.0 Case <Case>Presence: [1..1]Type: The Case block is composed of the following Case element(s):








Page 106









3.0 Confirmation <Conf>Presence: [1..1]Type: The Confirmation block is composed of the following DebitAuthorisationConfirmation element(s):


3.1 DebitAuthorisation <DbtAuthstn> [1..1] Indicator




3.1 DebitAuthorisation <DbtAuthstn>Presence: [1..1]Definition: Code expressing the decision taken by the account owner relative to the request for debit authorization.Data Type: One of the following YesNoIndicator values must be used:




Page 107

3.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount authorised for debit. The party providing the debit authority may want to authorise the amount less

charges and they may only be prepared to approve the debit for value today rather than the original value date.




3.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.Data Type: ISODate

3.4 Reason <Rsn>Presence: [0..1]Definition: Justification for partial authorisation of debit. Data Type: Max140TextFormat: maxLength: 140

minLength: 1

Business Example

The following illustrates one scenario for the DebitAuthorisationResponse workflow. This scenario is based on an initial RequestToModifyPayment scenario. The DebitAuthorisationResponse message is shown in Step 4 below. The scenario is based on the payment characteristics in the table below.


Description Value








Page 108


52317.48 GBP


/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/








<Id>CUSTA20050001</Id><Assgnr>CUASGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>



</RmtInf></Mod>

</camt.007.002.01>



Page 109





</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>



</RmtInf></Mod>

</camt.007.002.01>



<camt.030.001.01><Hdr>


</Hdr><Case>


</Case>



Page 110

<Assgnmt><Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>






</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Dtl>

<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy = "GBP">3743.52</AmtToDbt>

</Dtl></camt.037.001.01>



<camt.030.001.01><Hdr>

<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr>



Page 111

<To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>





</Assgnmt><Case>


</Case><Conf>


</camt.036.001.01>




<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne>



Page 112

<CreDtTm>2005-01-27T10:59:42</CreDtTm></Assgnmt><RslvdCase>


</RslvdCase><Sts>


</camt.029.001.01>







</RslvdCase><Sts>


</camt.029.001.01>



Page 113

Message: NotificationOfCaseAssignment <camt.030.001.01>Message Scope and UsageScopeThe NotificationOfCaseAssignment message is sent by a case assignee to a case creator/case assigner.

This message is used to inform the case assigner of further action that is undertaken by the case assignee to process the case, eg, the assignment of the case to a next case assignee.

Usage

The NotificationOfCaseAssignment message is used to notify the case creator/case assigner of further action undertaken by the case assignee in a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case

The NotificationOfCaseAssignment message covers one and only one case at a time. If the case assignee needs to inform a case creator/case assigner about several cases, then multiple NotificationOfCaseAssignment messages must be sent.

The NotificationOfCaseAssignment message must be forwarded by all subsequent case assigner(s) until it reaches the case creator.

The NotificationOfCaseAssignment message must not be used in place of a ResolutionOfInvestigation or a CaseStatusReport message.

OutlineThe NotificationOfCaseAssignment message is composed of four building blocks:



C.Report HeaderThis building block is mandatory.

D.Case Forwarding NotificationThis building block is mandatory.


Message: NotificationOfCaseAssignment <camt.030.001.01>

Page 114

Message Structure


Rule/ Guid.

No.1.0 Header <Hdr> [1..1]






Rule/ Guid.






Rule/ Guid.







Rule/ Guid.

No.4.0 Notification <Ntfctn> [1..1]

4.1 Justification <Justfn> [1..1] Code

Message Items DescriptionThe following section identifies the elements of the NotificationOfCaseAssignment message.



Page 115

1.0 Header <Hdr>Presence: [1..1]Definition: Specifies generic information about the notification.

The receiver of a notification is necessarily the party which assigned the case to the sender.Type: The Header block is composed of the following ReportHeader element(s):







minLength: 1

1.2 From <Fr>Presence: [1..1]Definition: Party reporting the status of the case.Data Type: AnyBICIdentifierFormat: [A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}Rule(s): AnyBICRule




1.4 CreationDateTime <CreDtTm>Presence: [1..1]Definition: Creation date and time of the report generation.



Page 116
















3.0 Assignment <Assgnmt>Presence: [1..1]



Page 117

Definition: Identifies the current assignment of the case.

The Assigner must be the emitter of the notification.The Assignee must be another Party in the payment chain.

Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1










Page 118


4.0 Notification <Ntfctn>Presence: [1..1]Definition: Information about the type of action taken.Type: The Notification block is composed of the following CaseForwardingNotification element(s):


4.1 Justification <Justfn> [1..1] Code

4.1 Justification <Justfn>Presence: [1..1]Definition: Justification for the forward action.Data Type: CodeOne of the following CaseForwardingNotification1Code values must be used:

Code Name DefinitionCANC RequestToCancel Case has been forwarded to the next Party for cancellation.

DTAU RequestDebitAuthorisation Case has been forwarded to obtain authorisation to debit.

FTHI FurtherInvestigation Case has been forwarded to the next Party for further investigation.

MODI RequestToModify Case has been forwarded to the next Party for modification.

SAIN SentAdditionalInformation Additonal information has been forwarded to the Creditor.

Business Example

The following illustrates one scenario for the NotificationOfCaseAssignment workflow. This scenario is based on an initial RequestToCancelPayment scenario. The NotificationOfCaseAssignment message is shown in Steps 2.2, 3.2 and 3.3 below. The scenario is based on the payment characteristics in the table below.

Customer A (BEI AAAAFRPP) instructed Bank B, Paris to execute a payment. The payment settles a series of invoices received in March and April 2005 and referenced in the remittance information of the payment instruction.

Description Value


Receiver Bank B, Paris (BBBBFRPP)

Instruction Reference CBPAY09876543




Page 119



Unstructured Remittance Information /INV/20050329/EUR8257.43/20050400104712//20050412/EUR4090.13/20050400204712/

Final Agent Bank C, Paris (CCCCFRPP)

Creditor Customer D, Paris (DDDDFRPP)Tristan Recording Studios

Scenario 1

NarrativeCustomer A checks its account payables. It appears that the invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer A requests the cancellation of the payment instruction.

Step 1Customer A requests the cancellation of the payment instruction to Bank B, Paris.

The following RequestToCancelPayment message is sent by Customer A to Bank B:XML Instance


<Id>AB20050417CANC</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>

</Assgnmt><Case>

<Id>AAAA200504001</Id><Cretr>AAAAFRPP</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>CBPAY09876543</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>

</Undrlyg><Justfn>

<CxlRsn>UPAY</CxlRsn></Justfn>

</camt.008.002.01>

Step 2Bank B assesses the RequestToCancelPayment message. After the necessary checks and look up of the original instruction, it appears that the instruction has already been forwarded to Bank C, under reference O1234598760. Bank B forwards the RequestToCancelPayment message to Bank C (Step 2.1) and notifies the case assignment to Customer A (Step 2.2).



Page 120

Step 2.1Bank B forwards the request to cancel the payment to Bank C.

The following RequestToCancelPayment message is sent by Bank B to Bank C:XML Instance


<Id>BBBBCANC0001200504</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T10:13:42</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>O1234598760</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 2.2Bank B notifies the case assignment to Customer A.

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

<camt.030.001.01><Hdr>

<Id>RCUSTB20050419</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-04-19T10:22:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>




Page 121

</camt.030.001.01>

Step 3Bank C receives the RequestToCancelPayment message from Bank B and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer D and Customer D has been informed (the Account Owner Reference is E20050418027, with value date 18 April 2005). Bank C requests the debit authorisation from Customer D (Step 3.1). At the same time, Bank C informs Bank B about its request to Customer D (Step 3.2). Upon receipt of the case assignment notification from Bank C, Bank B forwards the information to Customer A (Step 3.3).

Step 3.1Bank C requests a debit authorisation from Customer D.

The following DebitAuthorisationRequest message is sent by Bank C to Customer D:XML Instance


<Id>BNPRFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>E20050418027</AssgneInstrId><CcyAmt Ccy="EUR">12347.56</CcyAmt><ValDt>2005-04-18T00:00:00</ValDt>

</Undrlyg><Dtl>

<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy="EUR">12347.56</AmtToDbt>

</Dtl></camt.037.001.01>

Step 3.2Bank C informs Bank B about the debit authorisation request to Customer D.

The following NotificationOfCaseAssignment message is sent by Bank C to Bank B:XML Instance

<camt.030.001.01><Hdr>

<Id>RCCCCBBBB20050419004</Id><Fr>CCCCFRPP</Fr><To>BBBBFRPP</To><CreDtTm>2005-01-27T10:21:23</CreDtTm>

</Hdr><Case>



Page 122


</Case><Assgnmt>

<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3.3Upon receipt of the message from Bank C, Bank B confirms the case assignment to Customer A.

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

<camt.030.001.01><Hdr>

<Id>RBBBBAAAA20050419012</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-01-27T10:25:42</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Customer D, after further investigation, recognises that the payment was indeed not due and grants the debit authorisation to Bank C.

The following DebitAuthorisationResponse message is sent by Customer D to Bank C:XML Instance


<Id>RCCCCFDA20050419001</Id><Assgnr>DDDDFRPP</Assgnr>



Page 123

<Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T12:17:43</CreDtTm>

</Assgnmt><Case>


</Case><Conf>


</camt.036.001.01>

Step 5Bank C, upon receipt of the DebitAuthorisationResponse message, closes the case and informs Bank B that the investigation is resolved (Step 5.1). Bank C returns the corresponding funds to Customer A, via Bank B (not illustrated here). Bank B informs Customer A that the investigation is resolved, allowing the case closure(Step 5.2).

Step 5.1The following ResolutionOfInvestigation message is sent by Bank C to Bank B:XML Instance


<Id>CONFCCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T12:35:22</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 5.2The following ResolutionOfInvestigation message is sent by Bank B to Customer A:XML Instance


<Id>CONFBBBBCANC20050419013</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-04-19T12:43:11</CreDtTm>



</RslvdCase>



Page 124

<Sts><Conf>ACDA</Conf>

</Sts></camt.029.001.01>



Page 125

Message: RejectCaseAssignment <camt.031.001.01>Message Scope and UsageScopeThe RejectCaseAssignment message is sent by a case assignee to a case creator/case assigner.

This message is used to reject a case.

Usage

The RejectCaseAssignment message is used to notify the case creator/case assigner of the rejection of an assignment by the case assignee in a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case

Rejecting a case assignment occurs when the case assignee is unable to trace the original payment instruction or when the case assignee is unable, or does not have authority, to process the assigned case.

The RejectCaseAssignment message covers one and only one case at a time. If the case assignee needs to reject several case assignments, then multiple RejectCaseAssignment messages must be sent.

The RejectCaseAssignment message must be forwarded by all subsequent case assignee(s) until it reaches the case assigner.

The RejectCaseAssignment message must not be used in place of a ResolutionOfInvestigation or CaseStatusReport message.

OutlineThe RejectCaseAssignment message is composed of three building blocks:



C.Case Assignment Rejection JustificationThis building block is mandatory.

Message Structure


Message: RejectCaseAssignment <camt.031.001.01>

Page 126


Rule/ Guid.







Rule/ Guid.






Rule/ Guid.

No.3.0 Justification <Justfn> [1..1]

3.1 RejectionReason <RjctnRsn> [1..1] Code

Message Items DescriptionThe following section identifies the elements of the RejectCaseAssignment message.









Page 127


minLength: 1














Page 128













3.0 Justification <Justfn>Presence: [1..1]Definition: Specifies the reason for not accepting a Case.Type: The Justification block is composed of the following CaseAssignmentRejectionJustification element(s):


3.1 RejectionReason <RjctnRsn> [1..1] Code



Page 129

3.1 RejectionReason <RjctnRsn>Presence: [1..1]Definition: Reason for rejecting a case assignment.Data Type: CodeOne of the following CaseAssignmentRejection1Code values must be used:

Code Name DefinitionCNCL PaymentCancelled Used when the payment instruction has been cancelled.

NAUT NotAuthorisedToInvestigate Case Assignee is not allowed to investigate on this instruction (eg. Case Assignee is not the next party in the payment chain).

NFND UnderlyingPaymentNotFound

Underlying instruction can not be found.

RJCT PaymentRejected Used when the payment instruction has been rejected.

UKNW UnknownCase Used when receiving a ResolutionOfInvestigation or a DebitAuthorisation for an unknown case. It could be used as well when a party rejects a case status request.

Business Example

The following illustrates the usage of the RejectCaseAssignment message, based on a RequestToModifyPayment workflow.

Customer C (BEI CCCCJPJT) instructed Bank J in Japan (JJJJJPJT) to execute a payment on 23 January 2005. The payment settles a series of invoices received in January 2005 and referred to in the remittance information of the payment instruction.


Description Value

Sender Customer C (BEI CCCCJPJT)

Receiver Bank J, Tokyo (JJJJJPJT)

Instruction Reference 123JPY20050123



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

NarrativeOn 25 January 2005, Customer C checks its accounts payables. The payment should have been made to another final agent. As the execution of the payment instruction is foreseen for a future value date, Customer C requests the modification of the payment instruction and indicates the correct final agent.

Although the case may be forwarded to another financial institution, this scenario limits itself to the interaction between the customer and the first financial institution.

Step 1Customer C sends by mistake a request to modify payment to Bank V, instead of Bank J.

The following RequestToModifyPayment message is sent by Customer C to Bank V:XML Instance


<Id>ABCDEFGHIJKLMNOPQRST123456789012345</Id><Assgnr>CCCCJPJT</Assgnr><Assgne>VVVVJPJT</Assgne><CreDtTm>2005-01-25T10:35:43</CreDtTm>

</Assgnmt><Case>

<Id>MOD123JPY20050123</Id><Cretr>CCCCJPJT</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>123JPY20050123</AssgnrInstrId><CcyAmt Ccy = "JPY">4257567</CcyAmt><ValDt>2005-01-27T00:00:00</ValDt>

</Undrlyg><Mod>

<LastSttlmAgt><FinInstnId>

<BIC>LLLLJPJT</BIC></FinInstnId>

</LastSttlmAgt></Mod>

</camt.007.002.01>

Step 2Upon receipt of the RequestToModifyPayment message, Bank V investigates the original instruction but cannot trace it. Bank V therefore rejects the case assignment.

The following RejectCaseAssignment message is sent by Bank V to Customer C:XML Instance


<Id>ABCDEFGHIJKLMNOPQRST123456789012345</Id><Assgnr>VVVVJPJT</Assgnr><Assgne>CCCCJPJT</Assgne><CreDtTm>2005-01-25T11:07:38</CreDtTm>



Page 131

</Assgnmt><Case>

<Id>MOD123JPY20050123</Id><Cretr>CCCCJPJT</Cretr>

</Case><Justfn>

<RjctnRsn>NFND</RjctnRsn></Justfn>

</camt.031.001.01>



Page 132

Message: RequestForDuplicateInstruction <camt.033.001.01>Message Scope and UsageScopeThe RequestForDuplicateInstruction message is sent by the case assignee to the case creator/case assigner.

This message is used to request a copy of the original payment instruction considered in the case.

Usage

The RequestForDuplicateInstruction message must be answered with a DuplicateInstruction message.

The RequestForDuplicateInstruction message must be used when a case assignee requests a copy of the original payment instruction. This occurs, eg, when the case assignee cannot trace the payment instruction based on the elements mentioned in the case assignment message.

The RequestForDuplicateInstruction covers one and only one instruction at a time. If several payment instruction copies are needed by the case assignee, then multiple RequestForDuplicateInstruction messages must be sent.

The RequestForDuplicateInstruction message must be used exclusively between the case assignee and its case creator/case assigner.

OutlineThe RequestForDuplicateInstruction message is composed of two blocks:



Message Structure


Rule/ Guid.







Message: RequestForDuplicateInstruction <camt.033.001.01>

Page 133


Rule/ Guid.





Message Items DescriptionThe following section identifies the elements of the RequestForDuplicateInstruction message.

1.0 Assignment <Assgnmt>Presence: [1..1]Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1







Page 134





2.0 Case <Case>Presence: [1..1]Type: The Case block is composed of the following Case element(s):












Page 135





Business Example

The following illustrates the usage of the RequestForDuplicateInstruction message and the DuplicateInstruction message (as a reply to the request), based on a RequestToCancelPayment workflow. Although the request for cancellation may be pursued after full details of the original instruction have been provided, this scenario is limited to the provision of the duplicate instruction.

Customer B (BEI CUSBFRPP) instructed Bank F, Paris to execute a payment. The payment settles a series of invoices received in March and April 2005 and referred to in the remittance information of the payment instruction.Characteristics of the payment instruction are as follows:

Description Value

Sender Customer B (BEI CUSBFRPP)

Receiver Bank F, Paris (FFFFFRPP)






Final Agent Bank A, Paris (AAAAFRPP)

Creditor Customer C (BEI CUSCFRPP)Tristan Recording Studios

NarrativeCustomer B checks its account payables. The invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer B requests the cancellation of the payment instruction.

Step 1Customer B sends a request for cancellation of the payment to Bank F, Paris.



Page 136

The following RequestToCancelPayment message is sent by Customer B to Bank F:XML Instance


<Id>AB20050417CANC</Id><Assgnr>CUSBFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>

</Assgnmt><Case>

<Id>CUSB200504001</Id><Cretr>CUSBFRPP</Cretr>

</Case><Undrlyg>


</Undrlyg><Justfn>


</camt.008.002.01>

Step 2Bank F assesses the RequestToCancelPayment message. Although the RequestToCancelPayment message is correctly formatted, Bank F does not want to act upon the request solely based on the identity of the sender, amount, currency and value date. In the RequestToCancelPayment message shown above, the Assigner Instruction Identification element is missing.

Bank F therefore requests a copy of the original instruction to make sure the instruction to be cancelled is unambiguously identified.

The following RequestForDuplicateInstruction message is sent by Bank F to Customer B: XML Instance


<Id>REPAB20050417</Id><Assgnr>FFFFFRPP</Assgnr><Assgne>CUSBFRPP</Assgne><CreDtTm>2005-04-19T11:02:23</CreDtTm>

</Assgnmt><Case>


</Case></camt.033.001.01>

Step 3Customer B receives the request for duplicate instruction from Bank F and looks up the original instruction. He sends a copy of the original instruction to Bank F.

The following DuplicateInstruction message is sent by Customer B to Bank F:



Page 137

XML Instance<camt.034.001.01>

<Assgnmt><Id>DUPLAB20050417CANC</Id><Assgnr>CUSBFRPP</Assgnr><Assgne>FFFFFRPP</Assgne><CreDtTm>2005-04-19T11:08:32</CreDtTm>

</Assgnmt><Case>


</Case><DplctInstr>

<Tp>103</Tp><Cntnt>

:20:CBPAY09876543//:32A:050417EUR12347.56//:33B:EUR12347.56//:50A:CUSBFRPP//:59:Tristan Recording Studios //239 Bld Haussmann//75009 Paris//:71A:SHA

</Cntnt></DplctInstr>

</camt.034.001.01>



Page 138

Message: RequestToCancelPayment <camt.008.002.01>Message Scope and UsageScopeThe RequestToCancelPayment message is sent by a case creator/case assigner to a case assignee.

This message is used to request the cancellation of an original payment instruction.

Usage

The RequestToCancelPayment message must be answered with a:- ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested

cancellation- ResolutionOfInvestigation message with a negative final outcome when the case assignee could perform the

requested cancellation but fails to do so (too late, irrevocable instruction, ...)- RejectCaseAssignment message when the case assignee is unable or authorised to perform the requested cancellation- NotificationOfCaseAssignment message whene the case assignee forwards the case assignment to a subsequent

case assignee.

A RequestToCancelPayment message concerns one and only one original payment instruction at a time. If several original payment instructions need to be cancelled, then multiple RequestToCancelPayment messages must be sent.

When a case assignee successfully performs a cancellation, it must return the corresponding funds to the case assigner.

The funds must be forwarded by all subsequent case assigner(s) until they reach the case creator.

The processing of a request to cancel payment case may end with a DebitAuthorisationRequest message sent to the creditor by its account servicing institution.

The RequestToCancelPayment message may be used to escalate a case after an unsuccessful request to modify the payment. In this scenario, the case identification remains the same as in the original RequestToModifyPayment message and the element ReopenCaseIndication is set to yes.

Main characteristicsThe RequestToCancelPayment message has the following main characteristics:

Case Identification and Reason CodeThe case creator assigns a unique case identification and the reason code for the cancellation request. This information will be passed unchanged to all subsequent case assignee(s).

Cancellation of a cover paymentThe cancellation of a payment instruction for which cover is provided by a separate instruction always results in the cancellation of the whole transaction, including the cover. The case assignee performing the cancellation must initiate the return of funds to the case creator. The case assigner must not request the cancellation of the cover separately.


Message: RequestToCancelPayment <camt.008.002.01>

Page 139

Cancellation request initiatorsThe cancellation of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment instruction processing chain.

OutlineThe RequestToCancelPayment message is composed of four building blocks:




D.Debit Authorisation DetailsThis building block is optional.

Message Structure


Rule/ Guid.







Rule/ Guid.







Page 140


Rule/ Guid.







Rule/ Guid.





Message Items DescriptionThe following section identifies the elements of the RequestToCancelPayment message.

1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Identifies the assignment of a case from an assigner to an assignee.Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1



Page 141

















Page 142









3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the payment instruction to be cancelled.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):









Page 143

minLength: 1


minLength: 1






4.0 Justification <Justfn>Presence: [1..1]Definition: Defines the reason for requesting the cancellation.Type: The Justification block is composed of the following DebitAuthorisationDetails element(s):





4.1 CancellationReason <CxlRsn>Presence: [1..1]Definition: Indicates the reason for cancellation.Data Type: CodeOne of the following CancellationReason1Code values must be used:



Page 144

Code Name DefinitionAGNT IncorrectAgent Agent in the payment workflow is incorrect.

CURR IncorrectCurrency Currency of the payment is incorrect.

CUST RequestedByCustomer Cancellation requested by the Debtor.

DUPL DuplicatePayment Payment is a duplicate of another payment.

UPAY UnduePayment Payment is not justified.

4.2 AmountToDebit <AmtToDbt>Presence: [0..1]Definition: Amount of money to be transferred between the debtor and creditor, before charges.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.3 ValueDateToDebit <ValDtToDbt>Presence: [0..1]Definition: Value date for debiting the amount.Data Type: ISODate

Business Example

The following illustrates two scenarios for the RequestToCancelPayment workflow.

Scenario 1, resulting in a ResolutionOfInvestigation message There is no further assignment down the chain as the payment instruction is cancelled before execution by the case assignee.

Customer D (BEI DDDDDEFF) instructed Bank F, Frankfurt (FFFFDEFF) to execute a payment instruction.


Description Value

Sender Customer D (BEI DDDDDEFF)

Receiver Bank F, Frankfurt (FFFFDEFF)

Instruction Reference CDPAY20050423001





Page 145


Final Agent Bank G, Frankfurt (GGGGDEFF)

Creditor Customer E (BEI EEEEDEFF)Hanswagen GmBH

NarrativeOn 22 April 2005, Customer D checks its accounts payables. The payment made under reference CDPAY20050423-001 should not have been sent to Bank F for execution on 17 April 2005. This should have been a end of the month payment.

Customer D requests the cancellation of the payment instruction.

Step 1The following RequestToCancelPayment message is sent by Customer D to Bank F:XML Instance


<Id>CD20050423CANC</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>FFFFDEFF</Assgne><CreDtTm>2005-04-22T10:17:32</CreDtTm>

</Assgnmt><Case>

<Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>CDPAY20050423001</AssgnrInstrId><CcyAmt Ccy = "EUR">175000.00</CcyAmt><ValDt>2005-04-23T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 2Bank F assesses the RequestToCancelPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has not been processed yet and the cancellation can be performed. Bank F executes the cancellation and replies with a ResolutionOfInvestigation message to Customer D.

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


<Id>CONFFFFFCANC20050423001</Id><Assgnr>FFFFDEFF</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-04-22T10:23:42</CreDtTm>

</Assgnmt>



Page 146

<RslvdCase><Id>DDDD20050423001</Id><Cretr>DDDDDEFF</Cretr>

</RslvdCase><Sts>


</camt.029.001.01>


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


Receiver Bank B, Paris (BBBBFRPP)






Final Agent Bank C, Paris (CCCCFRPP)

Creditor Customer D, Paris (DDDDFRPP)Tristan Recording Studios

NarrativeCustomer A checks its account payables. It appears that the invoice received in March has been paid by other means and the invoice received in April was due in May 2005 only. Customer A requests the cancellation of the payment instruction.

Step 1Customer A requests the cancellation of the payment instruction to Bank B, Paris.

The following RequestToCancelPayment message is sent by Customer A to Bank B:XML Instance


<Id>AB20050417CANC</Id><Assgnr>AAAAFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T10:09:30</CreDtTm>

</Assgnmt><Case>



Page 147


</Case><Undrlyg>

<AssgnrInstrId>CBPAY09876543</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 2Bank B assesses the RequestToCancelPayment message. After the necessary checks and look up of the original instruction, it appears that the instruction has already been forwarded to Bank C, under reference O1234598760. Bank B forwards the RequestToCancelPayment message to Bank C (Step 2.1) and notifies the case assignment to Customer A (Step 2.2).

Step 2.1Bank B forwards the request to cancel the payment to Bank C.

The following RequestToCancelPayment message is sent by Bank B to Bank C:XML Instance



</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>O1234598760</AssgnrInstrId><CcyAmt Ccy = "EUR">12347.56</CcyAmt><ValDt>2005-04-17T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 2.2Bank B notifies the case assignment to Customer A.

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

<camt.030.001.01><Hdr>



Page 148

<Id>RCUSTB20050419</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-04-19T10:22:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank C receives the RequestToCancelPayment message from Bank B and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer D and Customer D has been informed (the Account Owner Reference is E20050418027, with value date 18 April 2005). Bank C requests the debit authorisation from Customer D (Step 3.1). At the same time, Bank C informs Bank B about its request to Customer D (Step 3.2). Upon receipt of the case assignment notification from Bank C, Bank B forwards the information to Customer A (Step 3.3).

Step 3.1Bank C requests a debit authorisation from Customer D.

The following DebitAuthorisationRequest message is sent by Bank C to Customer D:XML Instance


<Id>BNPRFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>E20050418027</AssgneInstrId><CcyAmt Ccy="EUR">12347.56</CcyAmt><ValDt>2005-04-18T00:00:00</ValDt>

</Undrlyg><Dtl>



Page 149

<CxlRsn>CUST</CxlRsn><AmtToDbt Ccy="EUR">12347.56</AmtToDbt>

</Dtl></camt.037.001.01>

Step 3.2Bank C informs Bank B about the debit authorisation request to Customer D.

The following NotificationOfCaseAssignment message is sent by Bank C to Bank B:XML Instance

<camt.030.001.01><Hdr>

<Id>RCCCCBBBB20050419004</Id><Fr>CCCCFRPP</Fr><To>BBBBFRPP</To><CreDtTm>2005-01-27T10:21:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3.3Upon receipt of the message from Bank C, Bank B confirms the case assignment to Customer A.

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

<camt.030.001.01><Hdr>

<Id>RBBBBAAAA20050419012</Id><Fr>BBBBFRPP</Fr><To>AAAAFRPP</To><CreDtTm>2005-01-27T10:25:42</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>

<Id>CCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr>



Page 150

<Assgne>DDDDFRPP</Assgne><CreDtTm>2005-04-19T10:19:02</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Customer D, after further investigation, recognises that the payment was indeed not due and grants the debit authorisation to Bank C.

The following DebitAuthorisationResponse message is sent by Customer D to Bank C:XML Instance


<Id>RCCCCFDA20050419001</Id><Assgnr>DDDDFRPP</Assgnr><Assgne>CCCCFRPP</Assgne><CreDtTm>2005-04-19T12:17:43</CreDtTm>

</Assgnmt><Case>


</Case><Conf>


</camt.036.001.01>

Step 5Bank C, upon receipt of the DebitAuthorisationResponse message, closes the case and informs Bank B that the investigation is resolved (Step 5.1). Bank C returns the corresponding funds to Customer A, via Bank B (not illustrated here). Bank B informs Customer A that the investigation is resolved, allowing the case closure (Step 5.2).

Step 5.1The following ResolutionOfInvestigation message is sent by Bank C to Bank B:XML Instance


<Id>CONFCCCCFDA20050419001</Id><Assgnr>CCCCFRPP</Assgnr><Assgne>BBBBFRPP</Assgne><CreDtTm>2005-04-19T12:35:22</CreDtTm>



</RslvdCase><Sts>



Page 151


</camt.029.001.01>

Step 5.2The following ResolutionOfInvestigation message is sent by Bank B to Customer A:XML Instance


<Id>CONFBBBBCANC20050419013</Id><Assgnr>BBBBFRPP</Assgnr><Assgne>AAAAFRPP</Assgne><CreDtTm>2005-04-19T12:43:11</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>



Page 152

Message: RequestToModifyPayment <camt.007.002.01>Message Scope and UsageScope

The RequestToModifyPayment message is sent by a case creator/case assigner to a case assignee.

This message is used to request the modification of characteristics of an original payment instruction.

Usage

The RequestToModifyPayment message must be answered with a:- ResolutionOfInvestigation message with a positive final outcome when the case assignee can perform the requested

modification- ResolutionOfInvestigation message with a negative final outcome when the case assignee could perform the

requested modification but fails to do so (too late, irrevocable instruction, one requested element cannot be modified, ...)

- RejectCaseAssignment message when the case assignee is unable or authorised to perform the requested modification- NotificationOfCaseAssignment message whenever the case assignee forwards the case assignment to a subsequent

case assignee.

The RequestToModifyPayment message covers one and only one original instruction at a time. If several original payment instructions need to be modified, then multiple RequestToModifyPayment messages must be sent.

The RequestToModifyPayment message can be sent to request the modification of one or several elements of the original payment instruction. If many elements need to be modified, it is recommended to cancel the original payment instruction and initiate a new one.

The RequestToModifyPayment must be processed on an all or nothing basis. If one of the elements to be modified cannot be altered, the assignment must be rejected in full (by means of a RejectCaseAssignment message) or not performed (by means of a negative ResolutionOfInvestigation message).

The RequestToModifyPayment message must never be sent to request the modification of the currency of the original payment instruction. A RequestToCancelPayment message must be used instead and a new payment instruction initiated.

The RequestToModifyPayment message may be forwarded to subsequent case assignee(s).

When a RequestToModifyPayment message is used to decrease the amount of the original payment instruction, the modification will trigger a return of funds from the case assignee to the case creator.

The RequestToModifyPayment message must never be sent to request the increase of the amount of the original payment instruction. A RequestToCancelPayment message must be used instead and a new payment instruction initiated. Alternatively, a new instruction with the complementary amount must be sent. In this latter case, this is not considered as an exception or investigation instruction.

Depending on the requested modification(s) and the processing stage of the original payment instruction, the processing of a request to modify payment case may end with one of the following:- an AdditionalPaymentInformation message sent to the creditor of the original payment instruction


Message: RequestToModifyPayment <camt.007.002.01>

Page 153

- a DebitAuthorisationRequest message sent to the creditor of the original payment instruction- a RequestToCancelPayment message sent to a subsequent case assignee

The RequestToModifyPayment message can be sent to correct characteristics of an original payment instruction following receipt of an UnableToApply message. In this scenario, the case identification will remain the same.

Main characteristicsThe RequestToModifyPayment message has the following main characteristics:

Case IdentificationThe case creator assigns a unique case identification. This information will be passed unchanged to all subsequent case assignee(s).

Modification of a cover paymentLowering the amount of an original payment instruction for which cover is provided by a separate instruction will systematically mean the modification of the whole transaction, including the cover. The case assignee performing the amount modification must initiate the return of funds in excess to the case creator.The modification of the agents' information on an original payment instruction for which cover is provided by a separate instruction will systematically mean the whole transaction is modified, ie, the cover is executed through the agent(s) mentioned in the RequestToModifyPayment message. The cover payment must not be modified separately.

Information that can be modifiedThe modification of a payment instruction can be initiated by either the debtor/creditor or any subsequent agent in the payment processing chain.

The case creator provides the information to be modified in line with agreements made with the case assignee. If the case assignee needs in turn to assign the case to a subsequent case assignee, the requested modification(s) must be in line with the agreement made with the next case assignee and a NotificationOfCaseAssignment message must be sent to the case assigner. Otherwise, the request to modify payment case must be rejected (by means of a negative ResolutionOfInvestigation message).

OutlineThe RequestToModifyPayment message is composed of four building blocks:

A. Case AssignmentThis building block is mandatory.

B. CaseThis building block is mandatory.

C. Payment Instruction ExtractThis building block is mandatory.

D. Requested ModificationThis building block is mandatory.



Page 154

Message Structure


Rule/ Guid.







Rule/ Guid.






Rule/ Guid.







Rule/ Guid.

No.4.0 Modification <Mod> [1..1]

4.1 RelatedReference <RltdRef> [0..1] Text

4.2 BankOperationCode <BkOprCd> [0..1] Code

4.3 InstructionCode <InstrCd> [0..1] Code

4.4 RequestedExecutionDate <ReqdExctnDt> [0..1] DateTime




Page 155


Rule/ Guid.

No.4.6 InterbankSettledAmount <IntrBkSttldAmt> [0..1] Amount

4.7 Debtor <Dbtr> [0..1] +




4.11 PaymentScheme <PmtSchme> [0..1]

4.12 {Or Code <Cd> [1..1] Code

4.13 Or} ProprietaryInformation <PrtryInf> [1..1] Text

4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct> [0..1] +



4.17 RemittanceInformation <RmtInf> [0..1]






4.23 {{Or DuePayableAmount <DuePyblAmt> [1..1] Amount




4.27 Or}} TaxAmount <TaxAmt> [1..1] Amount





4.32 Purpose <Purp> [0..1]

4.33 {Or Proprietary <Prtry> [1..1] Text

4.34 Or} Code <Cd> [1..1] Code

4.35 InstructionForFinalAgent <InstrForFnlAgt> [0..1]

4.36 Code <Cd> [0..2] Code

4.37 Proprietary <Prtry> [0..1] Text

4.38 DetailsOfCharges <DtlsOfChrgs> [0..1] Code




Page 156

Message Items DescriptionThe following section identifies the elements of the RequestToModifyPayment message.








minLength: 1









Page 157

















Page 158



3.0 Underlying <Undrlyg>Presence: [1..1]Definition: Identifies the Payment Transaction to modify.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):







minLength: 1


minLength: 1






Page 159



4.0 Modification <Mod>Presence: [1..1]Type: The Modification block is composed of the following RequestedModification element(s):


4.1 RelatedReference <RltdRef> [0..1] Text

4.2 BankOperationCode <BkOprCd> [0..1] Code

4.3 InstructionCode <InstrCd> [0..1] Code

4.4 RequestedExecutionDate <ReqdExctnDt> [0..1] DateTime


4.6 InterbankSettledAmount <IntrBkSttldAmt> [0..1] Amount

4.7 Debtor <Dbtr> [0..1] +




4.11 PaymentScheme <PmtSchme> [0..1]

4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct> [0..1] +



4.17 RemittanceInformation <RmtInf> [0..1]

4.32 Purpose <Purp> [0..1]

4.35 InstructionForFinalAgent <InstrForFnlAgt> [0..1]

4.38 DetailsOfCharges <DtlsOfChrgs> [0..1] Code


4.1 RelatedReference <RltdRef>Presence: [0..1]Definition: Reference relating to a linked payment instruction or agreement which is meaningful to both parties (eg, the

content of field 21 in a cover instruction).Data Type: Max35TextFormat: maxLength: 35

minLength: 1



Page 160

4.2 BankOperationCode <BkOprCd>Presence: [0..1]Definition: SWIFT defined service level applies to the payment instruction.Data Type: CodeWhen this message item is present, one of the following SWIFTServiceLevel2Code values must be used:

Code Name DefinitionSPAY SWIFTPay Credit transfer is to be processed according to the

SWIFTPay Service Level.

SSTD Standard Credit transfer is to be processed according to the Standard Service Level.

4.3 InstructionCode <InstrCd>Presence: [0..1]Definition: Further information related to the processing of the payment instruction. The instruction can relate to a level

of service between the bank and the customer, or give instructions to and for specific parties in the payment chain.

Data Type: CodeWhen this message item is present, one of the following Instruction1Code values must be used:

Code Name DefinitionPBEN PayTheBeneficiary Beneficiary to be paid only after verification of identity.

TFRO TimeFrom Payment instruction will be valid and eligible for execution from the date and time stipulated.

TTIL TimeTill Payment instruction is valid and eligible for execution until the date and time stipulated. Otherwise, the payment instruction will be rejected.

4.4 RequestedExecutionDate <ReqdExctnDt>Presence: [0..1]Definition: Date and time the originator (debtor or creditor) requests the clearing agent to process the payment instruction.Data Type: ISODate

4.5 ValueDate <ValDt>Presence: [0..1]Definition: Date on which the amount of money ceases to be available to theagent that owes the money, or when the

amount of money becomes available to the agent to which the money is due.Data Type: ISODate

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



Page 161

Format: CurrencyAndAmountfractionDigits: 5minInclusive: 0totalDigits: 18CurrencyCode[A-Z]{3,3}


4.7 Debtor <Dbtr>Presence: [0..1]Definition: Debtor or Ordering customer of the payment instruction.Type: This message item is composed of the following PartyIdentification1 element(s):






4.8 DebtorAccount <DbtrAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):







4.9 IntermediarySettlementAgent <IntrmySttlmAgt>Presence: [0..1]Definition: Party that executes a cash transfer received via a clearing agent or on request of an agreement party.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):






Page 162


4.10 LastSettlementAgent <LastSttlmAgt>Presence: [0..1]Definition: Party that executes a cash transfer received via a clearing agent or on request of an agreement party.Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification element(s):





4.11 PaymentScheme <PmtSchme>Presence: [0..1]Definition: Specification of a pre-agreed offering between clearing agents, or the channel through which the payment

instruction is to be processed. This payment scheme can point to a specific rulebook governing the rules of clearing and settlement between two parties.

Type: This message item is composed of one of the following PaymentSchemeChoice element(s):


4.12 {Or Code <Cd> [1..1] Code

4.13 Or} ProprietaryInformation <PrtryInf> [1..1] Text

4.12 Code <Cd>Presence: [1..1]This message item is part of choice 4.11 PaymentScheme.Definition: Specifies the channel through which the payment instruction is to be processed in coded form. Data Type: CodeOne of the following CashClearingSystem2Code values must be used:

Code Name DefinitionACH ACH Automated Clearing House. Payment system that clears

cash transfers and settles the proceeds in a lump sum, usually on a multilateral netting basis.

CHI CHIPS CHIPS is the Clearing House Interbank Payment System.

FDN FedNet FedNet is a link to a Federal Bank account via the internet. FedNet enables checking of account balance, transactions, take print outs of account statement, transfer funds to third party accounts, E-shopping, BSNL Payments, Deposit opening, Deposit Renewal, Request for Demand Draft, Cheque Book etc.



Page 163

Code Name DefinitionRTG RTGS Real Time Gross Settlement System. Payment system that

simultaneously clears individual transfers and settles them in central bank money.

4.13 ProprietaryInformation <PrtryInf>Presence: [1..1]This message item is part of choice 4.11 PaymentScheme.Definition: Channel that is specific to a user community and is required for use within that user community.

Usage : if the channel is included in the list of codes provided for the payment scheme, the code element should be used instead of the proprietary element.


minLength: 1

4.14 BeneficiaryInstitutionAccount <BnfcryInstnAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):







4.15 Creditor <Cdtr>Presence: [0..1]Definition: Entity involved in an activity.Type: This message item is composed of the following PartyIdentification1 element(s):








Page 164

4.16 CreditorAccount <CdtrAcct>Presence: [0..1]Definition: Account to or from which a cash entry is made.Type: This message item is composed of the following CashAccount3 element(s):







4.17 RemittanceInformation <RmtInf>Presence: [0..1]Definition: Structured information that enables the matching, ie, reconciliation, of a payment with the items that the

payment is intended to settle, eg, commercial invoices in an account receivable system.Type: This message item is composed of one of the following RemittanceInformation3Choice element(s):




4.18 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 4.17 RemittanceInformation.Definition: Information, in free text form, to enable the matching, ie reconciliation, (reconciliation) of a payment with

the items that the payment is intended to settle, such as commercial invoices in an accounts receivable system.Data Type: Max140TextFormat: maxLength: 140

minLength: 1

4.19 Structured <Strd>Presence: [1..1]This message item is part of choice 4.17 RemittanceInformation.Definition: Information in structured form, that is supplied to enable the matching, ie, reconciliation, of a payment with

the items that the payment is intended to settle, eg, commercial invoices in an account receivable system. Type: This message item is composed of the following StructuredRemittanceInformation2 element(s):





Page 165








4.20 ReferredDocumentType <RfrdDocTp>Presence: [0..1]Definition: Specifies the nature of the referred document/transaction, eg, invoice or credit note.Data Type: CodeWhen this message item is present, one of the following DocumentType1Code values must be used:

Code Name DefinitionCINV CommercialInvoice Document is an invoice.

CMCN CommercialContract Document is an agreement between the parties, stipulating the terms and conditions of the delivery of goods or services.

CNFA CreditNoteRelatedToFinancialAdjustment

Document is a credit note for the final amount settled for a commercial transaction.

CREN CreditNote Document is a credit note.

DEBN DebitNote Document is a debit note.

DNFA DebitNoteRelatedToFinancialAdjustment

Document is a debit note for the final amount settled for a commercial transaction.

FXDR ForeignExchangeDealReference

Document is a pre-agreed or pre-arranged foreign exchange transaction to which the payment transaction refers.

HIRI HireInvoice Document is an invoice for the hiring of human resources or renting goods or equipment.

MSIN MeteredServiceInvoice Document is an invoice claiming payment for the supply of metered services, eg, gas or electricity, supplied to a fixed meter.

RADM RemittanceAdviceMessage Document is a remittance advice sent separately from the current transaction.

RPIN RelatedPaymentInstruction Document is a linked payment instruction to which the current payment instruction is related, eg, in a cover scenario.

SBIN SelfBilledInvoice Document is an invoice issued by the debtor.

SOAC StatementOfAccount Document is a statement of the transactions posted to the debtor's account at the supplier.



Page 166

4.21 ReferredDocumentRelatedDate <RfrdDocRltdDt>Presence: [0..1]Definition: Date associated with the referred document, eg, date of issue. Data Type: ISODate

4.22 ReferredDocumentAmount <RfrdDocAmt>Presence: [0..n]Definition: Amount of money and currency of a document referred to in the remittance section. The amount is typically

either the original amount due and payable, or the amount actually remitted for the referred document.Type: This message item is composed of one of the following ReferredDocumentAmount1Choice element(s):


4.23 {Or DuePayableAmount <DuePyblAmt> [1..1] Amount




4.27 Or} TaxAmount <TaxAmt> [1..1] Amount

4.23 DuePayableAmount <DuePyblAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount specified is the exact amount due and payable to the creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.24 DiscountAppliedAmount <DscntApldAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount of money resulting from the application of an agreed discount to the amount due and payable to the

creditor.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount

fractionDigits: 5minInclusive: 0totalDigits: 18



Page 167

CurrencyCode[A-Z]{3,3}


4.25 RemittedAmount <RmtdAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount of money remitted for the referred document.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.26 CreditNoteAmount <CdtNoteAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Amount specified for the referred document is the amount of a credit note.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount



4.27 TaxAmount <TaxAmt>Presence: [1..1]This message item is part of choice 4.22 ReferredDocumentAmount.Definition: Quantity of cash resulting from the calculation of the tax.Data Type: CurrencyAndAmountThis data type must be used with the following XML Attribute: Currency (Ccy) which is typed by CurrencyCode.Format: CurrencyAndAmount




Page 168


4.28 DocumentReferenceNumber <DocRefNb>Presence: [0..1]Definition: Unique and unambiguous identification of a document that distinguishes that document from another

document referred to in the remittance information, usually assigned by the originator of the referred document/transaction.


minLength: 1

4.29 CreditorReference <CdtrRef>Presence: [0..1]Definition: Unique and unambiguous reference assigned by the creditor to refer to the payment transaction.

Usage: if available, the initiating party should provide this reference in the structured remittance information, to enable reconciliation by the creditor upon receipt of the cash.

If the business context requires the use of a creditor reference or a payment remit identification, and only one identifier can be passed through the end-to-end chain, the creditor's reference or payment remittance identification should be quoted in the end-to-end transaction identification.


minLength: 1

4.30 Invoicer <Invcr>Presence: [0..1]Definition: Identification of the organization issuing the invoice when different than the creditor or final party Type: This message item is composed of the following PartyIdentification1 element(s):






4.31 Invoicee <Invcee>Presence: [0..1]Definition: Identification of the party to whom an invoice is issued, when different than the originator or debtor.Type: This message item is composed of the following PartyIdentification1 element(s):





Page 169





4.32 Purpose <Purp>Presence: [0..1]Definition: Underlying reason for the payment transaction, eg, a charity payment, or a commercial agreement between

the creditor and the debtor.Type: This message item is composed of one of the following PurposeChoice element(s):


4.33 {Or Proprietary <Prtry> [1..1] Text

4.34 Or} Code <Cd> [1..1] Code

4.33 Proprietary <Prtry>Presence: [1..1]This message item is part of choice 4.32 Purpose.Definition: Payment transaction purpose that is specific to a user community and is required for use within that user

community.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

4.34 Code <Cd>Presence: [1..1]This message item is part of choice 4.32 Purpose.Definition: Specifies the type of transaction that resulted in the payment initiation in coded form Data Type: CodeOne of the following PaymentPurpose1Code values must be used:

Code Name DefinitionADVA AdvancePayment Transaction is an advance payment.

AGRT AgriculturalTransfer Transaction is related to the agricultural domain.

ALMY AlimonyPayment Transaction is the payment of alimony.

BECH ChildBenefit Transaction is related to a payment made to assist parent/guardian to maintain child.

BENE UnemploymentDisabilityBenefit

Transaction is related to a payment to a person who is unemployed/disabled.

BONU BonusPayment. Transaction is related to payment of a bonus.

CASH CashManagementTransfer Transaction is a general cash management instruction.



Page 170

Code Name DefinitionCBFF CapitalBuilding Transaction is related to capital building fringe fortune, ie

capital building for retirement.

CHAR CharityPayment Transaction is a payment for charity reasons.

CMDT CommodityTransfer Transaction is payment of commodities.

COLL CollectionPayment Collection of funds initiated via a credit transfer.

COMC CommercialCredit Transaction is payment of commercial credit.

COMM Commission Transaction is payment of commission.

COMT ConsumerThirdPartyConsolidatedPayment

Payment used by a third party who can collect funds to pay on behalf of consumers, ie credit counseling or bill payment companies.

COST Costs Transaction is related to payment of costs.

CPYR Copyright Transaction is payment of copyright.

DBTC DebitCollectionPayment Collection of funds initiated via a debit transfer.

DIVI Dividend Transaction is payment of dividends.

FREX ForeignExchange Transaction is related to a foreign exchange operation.

GDDS PurchaseSaleOfGoods Transaction is related to purchase and sale of goods.

GOVT GovernmentPayment Transaction is a payment to or from a government department.

HEDG Hedging Transaction is related to a hedging operation.

IHRP InstalmentHirePurchaseAgreement

Transaction is payment for an installment/hire-purchase agreement.

INSU InsurancePremium Transaction is payment of an insurance premium.

INTC IntraCompanyPayment Transaction is an intra-company payment, ie, a payment between two companies belonging to the same group.

INTE Interest Transaction is payment of interest.

LICF LicenseFee Transaction is payment of a license fee.

LOAN Loan Transaction is related to transfer of loan to borrower.

LOAR LoanRepayment Transaction is related to repayment of loan to lender.

NETT Netting Transaction is related to a netting operation.

PAYR Payroll Transaction is related to the payment of payroll.

PENS PensionPayment Transaction is the payment of pension.

REFU Refund Transaction is the payment of a refund.

RENT Rent Transaction is the payment of rent.

ROYA Royalties Transaction is the payment of royalties.

SALA SalaryPayment Transaction is the payment of salaries.

SCVE PurchaseSaleOfServices Transaction is related to purchase and sale of services.

SECU Securities Transaction is the payment of securities.



Page 171

Code Name DefinitionSSBE SocialSecurityBenefit Transaction is a social security benefit, ie payment made by

a government to support individuals.

SUBS Subscription Transaction is the payment of a subscription.

SUPP SupplierPayment Transaction is related to a payment to a supplier.

TAXS TaxPayment Transaction is the payment of taxes

TREA TreasuryPayment Transaction is related to treasury operations.

VATX ValueAddedTaxPayment Transaction is the payment of value added tax.

4.35 InstructionForFinalAgent <InstrForFnlAgt>Presence: [0..1]Definition: Further information related to the processing of the payment instruction. The instruction can relate to a level

of service between the bank and the customer, or give instructions to and for specific parties in the payment chain.

Type: This message item is composed of the following InstructionForFinalAgent element(s):


4.36 Code <Cd> [0..2] Code

4.37 Proprietary <Prtry> [0..1] Text

4.36 Code <Cd>Presence: [0..2]Definition: Further information related to the processing of the payment instruction, provided by the initiating party,

and intended for the final agent, in coded form.Data Type: CodeWhen this message item is present, one of the following Instruction3Code values must be used:

Code Name DefinitionCHQB PayCreditorByCheque Beneficiary must be paid by cheque.

HOLD HoldCashForCreditor Cash must be held for the beneficiary, who will call.. Pay on identification.

PHOB PhoneBeneficiary Please advise/contact beneficiary/claimant by phone

TELB Telecom Please advise/contact beneficiary/claimant by the most efficient means of telecommunication.

4.37 Proprietary <Prtry>Presence: [0..1]Definition: Instruction to the final agent that is specific to a user community and is required for use within that user

community.



Page 172

Usage : The proprietary element should only be used when the coded element does not provide sufficient codes or when the selected code in the coded element needs to be supplemented by additional information such as a passport number or telephone number.


minLength: 1

4.38 DetailsOfCharges <DtlsOfChrgs>Presence: [0..1]Definition: Party(ies) liable for a charge associated with the transfer of cash.Data Type: CodeWhen this message item is present, one of the following ChargeBearer1Code values must be used:

Code Name DefinitionBEN BorneByCreditor All transaction charges are to be borne by the creditor.

OUR BorneByDebtor All transaction charges are to be borne by the debtor.

SHA Shared Under the credit transfer scenario, transaction charges on the sender's side are to be borne by the debtor; transaction charges on the receiver's side are to be borne by the creditor.

4.39 SenderToReceiverInformation <SndrToRcvrInf>Presence: [0..6]Definition: Unformatted information from the sender to the receiver.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

Business Example

The following illustrates three scenarios for the RequestToModifyPayment workflow. All scenarios are based on the payment characteristics in the table below.


Description Value







52317.48 GBP



Page 173


/INV/20041223/GBP23257./20050100104712//20050113/29060.48/20050100204712/



Scenario 1, resulting in an AdditionalPaymentInformation message

NarrativeCustomer A checks its accounts payables. The dates for the two invoices have been incorrectly reported in the remittance information.

Step 1Customer A decides to request the modification of the payment instruction in order for the creditor to automatically reconcile the accounts receivables with the payment instruction amount. Customer A makes a request for modification of the payment instruction to change the remittance information content.




</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>

Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to forward the RequestToModifyPayment message to Bank K (Step 2.1). At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).



Page 174

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

The following RequestToModifyPayment message is sent by Bank A to Bank K:XML Instance



</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>

Step 2.2 Bank A informs Customer A of the case assignment to Bank K.


<camt.030.001.01><Hdr>


</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>

<Justfn>MODI</Justfn>



Page 175

</Ntfctn></camt.030.001.01>

Step 3Bank K receives the RequestToModifyPayment message from Bank A and checks the status of the instruction. The instruction has been correctly executed. The credit has been passed onto the account of Customer S and the customer has been informed. Bank K forwards the correct remittance information content to Customer S, using an AdditionalPaymentInformation message (Step 3.1). At the same time, as there is no further processing needed, a ResolutionOfInvestigation message is sent to Bank A, notifying that the information has been delivered to the customer (Step 3.2). Bank A in turn reverts to Customer A with a ResolutionOfInvestigation message (Step 3.3).

Step 3.1Bank K forwards additional information about the payment to Customer S.

The following AdditionalPaymentInformation message is sent by Bank K to Customer S:XML Instance


<Id>I103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>ASUPGB2L</Assgne><CreDtTm>2005-01-27T08:52:30</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>I1030123456789</AssgnrInstrId></Undrlyg><Inf>

<RmtChc><Ustrd>/INV/20041212/GBP23257./20050100104712//20050124/29060.48/20050100204712/</Ustrd>

</RmtChc><Cdtr>

<Nm>All Supplies and Co</Nm><Id>

<OrgId><BEI>CUSBGB2L</BEI>

</OrgId></Id>

</Cdtr></Inf>

</camt.028.001.01>

Step 3.2Bank K informs Bank A of the resolution of the investigation.

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

<camt.029.001.01>



Page 176

<Assgnmt><Id>RKKKKAAAA20050127004</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T09:08:23</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 3.3Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A of the resolution of the investigation.



<Id>RAAAACUSA20050127004</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CUSAGB2L</Assgne><CreDtTm>2005-01-27T09:18:23</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Scenario 2, resulting in a RequestToCancelPayment message

NarrativeCustomer A checks its accounts payables. The invoices are payable to the account of Customer C with Bank W (WWWWGB2L) instead of Bank K.

Step 1Customer A makes a request for modification of the payment instruction to change the final agent (creditor's financial institution).


<camt.007.002.01>



Page 177

<Assgnmt><Id>CUSTA20050001</Id><Assgnr>CUSAGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:35:30</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>

<LastSttlmAgt><FinInstnId>

<BIC>WWWWGB2L</BIC></FinInstnId>

</LastSttlmAgt></Mod>

</camt.007.002.01>

Step 2Bank A assesses the RequestToModifyPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has already been forwarded to Bank K, under reference 1030123456789. Bank A needs to request the cancellation of the instruction to Bank K (Step 2.1) and re issue the instruction to Bank W. (This new instruction is not illustrated here) At the same time, Bank A informs Customer A of the case assignment to Bank K (Step 2.2).

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

The following RequestToCancelPayment message is sent by Bank A to Bank K:XML Instance



</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Justfn>



Page 178

<CxlRsn>AGNT</CxlRsn></Justfn>

</camt.008.002.01>



<camt.030.001.01><Hdr>


</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank K receives the RequestToCancelPayment message from Bank A and checks the status of the instruction. The credit has not yet been passed onto the account of Customer S. Bank K cancels the instruction and reverts to Bank A with a ResolutionOfInvestigation message. If the instruction had been settled between Bank A and Bank K, a return of funds would be necessary (not illustrated in this scenario).



<Id>RC103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T08:54:30</CreDtTm>



</RslvdCase><Sts>



Page 179


</camt.029.001.01>

Step 4Upon receipt of the message from Bank K, Bank A closes the case and informs Customer A at the resolution of the investigation.






</RslvdCase><Sts>


</camt.029.001.01>







</Assgnmt><Case>




Page 180

</Case><Undrlyg>


</Undrlyg><Mod>



</RmtInf></Mod>

</camt.007.002.01>





</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Mod>



</RmtInf></Mod>

</camt.007.002.01>




Page 181


<camt.030.001.01><Hdr>


</Hdr><Case>


</Case><Assgnmt>

<Id>Q103AAAAKKKK20050127001</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>KKKKGB2L</Assgne><CreDtTm>2005-01-27T08:43:30</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>






</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Dtl>

<CxlRsn>CUST</CxlRsn>



Page 182

<AmtToDbt Ccy = "GBP">3743.52</AmtToDbt></Dtl>

</camt.037.001.01>



<camt.030.001.01><Hdr>

<Id>KKKKAAAA20050127004</Id><Fr>KKKKGB2L</Fr><To>AAAAGB2L</To><CreDtTm>2005-01-27T08:55:00</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>





</Assgnmt><Case>


</Case><Conf>


</camt.036.001.01>



Page 183




<Id>R103AAAAKKKK20050127001</Id><Assgnr>KKKKGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-01-27T10:59:42</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>







</RslvdCase><Sts>


</camt.029.001.01>



Page 184

Message: ResolutionOfInvestigation <camt.029.001.01>Message Scope and UsageScopeThe ResolutionOfInvestigation message is sent by a case assignee to a case creator/case assigner.

This message is used to inform of the resolution of a case, and optionally provides details about the corrective action undertaken by the case assignee.

Usage

The ResolutionOfInvestigation message is used by the case assignee to inform a case creator/case assigner about the resolution of a:- request to cancel payment case- request to modify payment case- unable to apply case- claim non receipt case

The ResolutionOfInvestigation message covers one and only one case at a time. If the case assignee needs to communicate about several cases, then several ResolutionOfInvestigation messages must be sent.

The ResolutionOfInvestigation message provides:- the final outcome of the case, whether positive or negative- optionally, the details of the corrective action undertaken by the case assignee

Whenever a payment instruction has been generated to solve the case under investigation, the optional CorrectionTransaction component present in the message must be completed.

The ResolutionOfInvestigation message must be forwarded by all subsequent case assignee(s) until it reaches the case creator.

The ResolutionOfInvestigation message must not be used in place of a RejectCaseAssignment or CaseStatusReport or NotificationOfAssignment message.

OutlineThe ResolutionOfInvestigation message is composed of four building blocks:



C.Payment Instruction ExtractThis building block is optional.


Message: ResolutionOfInvestigation <camt.029.001.01>

Page 185

D. Investigation Status ChoiceThis building block is optional.

Message Structure


Rule/ Guid.







Rule/ Guid.

No.2.0 ResolvedCase <RslvdCase> [1..1]





Rule/ Guid.

No.3.0 Status <Sts> [0..1]

3.1 {Or Confirmation <Conf> [1..1] Code

3.2 Or RejectedModification <RjctdMod> [1..14] Code

3.3 Or RejectedCancellation <RjctdCxl> [1..1]

3.4 ReasonCode <RsnCd> [1..1] Code


3.6 Or DuplicateOf <DplctOf> [1..1]




3.10 Or} AssignmentCancellationConfirmation <AssgnmtCxlConf> [1..1] Indicator



Page 186


Rule/ Guid.

No.4.0 CorrectionTransaction <CrrctnTx> [0..1]





Message Items DescriptionThe following section identifies the elements of the ResolutionOfInvestigation message.

1.0 Assignment <Assgnmt>Presence: [1..1]Definition: Note: the Assigner must be the sender of this confirmation and the Assignee must be the receiver.Type: The Assignment block is composed of the following CaseAssignment element(s):







minLength: 1




Example:



Page 187

<Assgnr>CORPBE22</Assgnr>





2.0 ResolvedCase <RslvdCase>Presence: [1..1]Definition: Identifies a resolved case.Type: The ResolvedCase block is composed of the following Case element(s):









Data Type: AnyBICIdentifier



Page 188

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





3.0 Status <Sts>Presence: [0..1]Definition: Indicates the status of the investigation.Type: The Status block is composed of one of the following InvestigationStatusChoice element(s):


3.1 {Or Confirmation <Conf> [1..1] Code

3.2 Or RejectedModification <RjctdMod> [1..14] Code

3.3 Or RejectedCancellation <RjctdCxl> [1..1]

3.6 Or DuplicateOf <DplctOf> [1..1]

3.10 Or} AssignmentCancellationConfirmation <AssgnmtCxlConf> [1..1] Indicator

3.1 Confirmation <Conf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Indicates the status of an investigation.Data Type: CodeOne of the following InvestigationExecutionConfirmation1Code values must be used:

Code Name DefinitionACDA AcceptedDebitAuthorisation Returned when a creditor accepts the debit authorisation.

CNCL CancelledAsPerRequest Returned when a requested cancellation is successfull.

CONF ConfirmationOfPayment Returned when a payment has been checked and was correctly executed.

CWFW CancellationWillFollow Returned when a payment will be cancelled to solve an investigation case.

ICOV CoverInitiated Returned when a transfer of funds has been initiated (a cover payment) to resolve a case.



Page 189

Code Name DefinitionINFO AdditionalInformationSent Returned when additional information has been sent to the

beneficiary of a payment.

IPAY PaymentInitiated Returned when the result of an investigation is the initiation of payment instruction.

IPYI PaymentInstructionInitiated Returned when a payment instruction (eg. MT103) has been initiated to resolve a case.

MCOV CoverModified Returned when a transfer of funds has been modified (a cover payment) to resolve a case.

MODI ModifiedAsPerRequest Returned when a requested modification is successfull.

3.2 RejectedModification <RjctdMod>Presence: [1..14]This message item is part of choice 3.0 Status.Definition: Indicates the reason for rejecting a modification.Data Type: CodeOne of the following PaymentModificationRejection1Code values must be used:

Code Name DefinitionUM01 UnableToModifyRelatedRef

erenceRelatedReference cannot be modified.

UM02 UnableToModifyBankOperationCode

BankOperationCode cannot be modified.

UM03 UnableToModifyInstructionCode

InstructionCode cannot be modified.

UM04 UnableToModifyRequestedExecutionDate

RequestedExecutionDate cannot be modified.

UM05 UnableToModifyValueDate ValueDate cannot be modified.

UM06 UnableToModifyInterbankSettlementAccount

InterbankSettlementAccount cannot be modified.

UM07 UnableToModifyDebtor Debtor cannot be modified.

UM08 UnableToModifyDebtorAccount

DebtorAccount cannot be modified.

UM09 UnableToModifyReceiverCorrespondent

ReceiverCorrespondent cannot be modified.

UM10 UnableToModifyThirdReimbursementInstitution

ThirdReimbursementInstitution cannot be modified.

UM11 UnableToModifyPaymentScheme

PaymentScheme cannot be modified.

UM12 UnableToModifyAccountofBeneficiaryInstitution

AccountOfBeneficiaryInstitution cannot be modified.

UM13 UnableToModifyCreditor Creditor cannot be modified.



Page 190

Code Name DefinitionUM14 UnableToModifyCreditorAc

countCreditorAccount cannot be modified.

UM15 UnableToModifyRemittanceInformation

RemittanceInformation cannot be modified.

UM16 UnableToModifyPaymentPurpose

PaymentPurpose cannot be modified.

UM17 UnableToModifyDetailsOfCharges

DetailsOfCharges cannot be modified.

UM18 UnableToModifySenderToReceiverInformation

SenderToReceiver cannot be modified.

UM19 UnableToModifyInstructionForFinalAgent

InstructionForFinalAgent cannot be modified.

UM20 InstructionCancelledSubmitNewInstruction

Used to inform of cancellation and request a new payment instruction. This should only be used if an agent does not want to modify a pending payment.

UM21 UnableToModifySubmitCancellation

Modification is not possible and the cancellation is requested.

3.3 RejectedCancellation <RjctdCxl>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Explains the reason for rejecting a payment cancellation request.Type: This message item is composed of the following RejectedCancellationJustification element(s):


3.4 ReasonCode <RsnCd> [1..1] Code


3.4 ReasonCode <RsnCd>Presence: [1..1]Definition: Justification for the rejection of the cancellation.Data Type: CodeOne of the following PaymentCancellationRejection1Code values must be used:

Code Name DefinitionAGNT AgentDecision Reported when the cancellation cannot be accepted because

of an agent refuses to cancel.

CUST CustomerDecision Reported when the cancellation cannot be accepted because of a customer decision (Creditor).

LEGL LegalDecision Reported when the cancellation cannot be accepted because of regulatory rules.



Page 191

3.5 Reason <Rsn>Presence: [0..1]Definition: Free text justification for rejecting a cancellation.Data Type: Max140TextFormat: maxLength: 140

minLength: 1

3.6 DuplicateOf <DplctOf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: Identifies a duplicated case. When present, the case identified in the message must be closed. The case

identified as duplicated (in this component) will be pursued.Type: This message item is composed of the following Case element(s):














Page 192



3.10 AssignmentCancellationConfirmation <AssgnmtCxlConf>Presence: [1..1]This message item is part of choice 3.0 Status.Definition: If yes, it means the cancellation of the assignment is confirmed.

If no, it means the cancellation of the assignment is rejected and the investigation process will continue.Data Type: One of the following YesNoIndicator values must be used:


4.0 CorrectionTransaction <CrrctnTx>Presence: [0..1]Definition: References a transaction intitiated to fix the case under investigation.Type: The CorrectionTransaction block is composed of the following PaymentInstructionExtract element(s):







minLength: 1


minLength: 1

4.3 CurrencyAmount <CcyAmt>Presence: [0..1]



Page 193

Definition: Amount of the payment. Depending on the context it can be either the amount settled (UnableToApply) or the instructed amount (RequestToCancel, RequestToModify, ClaimNonReceipt).





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.


Description Value

Sender Customer D (BEI DDDDDEFF)

Receiver Bank F, Frankfurt (FFFFDEFF)

Instruction Reference CDPAY20050423001




Final Agent Bank G, Frankfurt (GGGGDEFF)

Creditor Customer E (BEI EEEEDEFF)Hanswagen GmBH

NarrativeOn 22 April 2005, Customer D checks its accounts payables. The payment made under reference CDPAY20050423-001 should not have been sent to Bank F for execution on 17 April 2005. This should have been a end of the month payment.



Page 194

Customer D requests the cancellation of the payment instruction.

Step 1The following RequestToCancelPayment message is sent by Customer D to Bank F:XML Instance


<Id>CD20050423CANC</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>FFFFDEFF</Assgne><CreDtTm>2005-04-22T10:17:32</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>CDPAY20050423001</AssgnrInstrId><CcyAmt Ccy = "EUR">175000.00</CcyAmt><ValDt>2005-04-23T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 2Bank F assesses the RequestToCancelPayment message. After the necessary checks and look up of the original transaction, it appears that the instruction has not been processed yet and the cancellation can be performed. Bank F executes the cancellation and replies with a ResolutionOfInvestigation message to Customer D.

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


<Id>CONFFFFFCANC20050423001</Id><Assgnr>FFFFDEFF</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-04-22T10:23:42</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>



Page 195

Message: UnableToApply <camt.026.001.01>Message Scope and UsageScopeThe UnableToApply message is sent by a case creator/case assigner to a case assignee.This message is used to initiate an investigation of a payment instruction that cannot be executed or reconciled.

Usage

The unable to apply case occurs in two situations:- an agent cannot execute the payment instruction due to missing or incorrect information- a creditor/debtor cannot reconcile the payment entry as it is received unexpectedly, or missing or incorrect

information prevents reconciliation

The UnableToApply message always follows the reverse route of the original payment instruction.

The UnableToApply message must be forwarded to the preceding agents in the payment processing chain, as relevant.

The UnableToApply message covers one and only one payment instruction or payment entry at a time. If several payment instructions cannot be executed or several payment entries cannot be reconciled, then multiple UnableToApply messages must be sent.

Depending on the result of the analysis of the original payment instruction processing by a case assignee (incorrect routing, errors/omissions when processing the instruction, or no error) and the processing stage of the payment instruction, the unable to apply case may be viewed as a:- RequestToCancelPayment message, sent to the subsequent agent in the payment processing chain, if the original

payment instruction has been incorrectly routed through the chain of agents (this also entails a new corrected payment instruction is issued)

- RequestToModifyPayment message, sent to the subsequent agent in the payment processing chain, if a truncation or omission has occurred during the processing of the original payment instruction.

- DebitAuthorisationRequest message, sent to the case creator/case assigner, if the payment instruction has reached an incorrect creditor

- AdditionalPaymentInformation message, sent to the case creator/case assigner, if a truncation or omission in a payment instruction prevented reconciliation.

Main characteristicsThe UnableToApply message has the following main characteristics:

Case Identification and Reason CodeThe case creator (the instructed party/creditor of a payment instruction) assigns a unique case identification and optionally the reason code for the UnableToApply message. This information will be passed unchanged to all subsequent case assignee(s).

Underlying Payment Instruction IdentificationThe case creator specifies the identification of the underlying payment instruction.This identification needs to be updated by the subsequent case assigner(s) in order to match the one used with their case assignee(s).


Message: UnableToApply <camt.026.001.01>

Page 196

Unable To Apply JustificationThe UnableToApplyJustificationChoice element allows to indicate whether a specific element causes the unable to apply situation (incorrect element and/or mismatched element can be listed) or whether any supplementary information needs to be forwarded.

OutlineThe UnableToApply message is composed of four building blocks:




D.Unable to Apply Justification ChoiceThis building block is mandatory.

Message Structure


Rule/ Guid.







Rule/ Guid.







Page 197


Rule/ Guid.







Rule/ Guid.


4.1 {Or AnyInformation <AnyInf> [1..1] Indicator

4.2 Or} MissingOrIncorrectInformation <MssngOrIncrrctInf> [1..1]

4.3 MissingInformation <MssngInf> [0..10] Code

4.4 IncorrectInformation <IncrrctInf> [0..10] Code

Message Items DescriptionThe following section identifies the elements of the UnableToApply message.








minLength: 1



Page 198

















Page 199









3.0 Underlying <Undrlyg>Presence: [1..1]Definition: References the Payment Instruction that a Party is unable to execute or unable to reconcile.Type: The Underlying block is composed of the following PaymentInstructionExtract element(s):









Page 200

minLength: 1


minLength: 1






4.0 Justification <Justfn>Presence: [1..1]Definition: Explains the reason why unable to apply.Type: The Justification block is composed of one of the following UnableToApplyJustificationChoice element(s):


4.1 {Or AnyInformation <AnyInf> [1..1] Indicator

4.2 Or} MissingOrIncorrectInformation <MssngOrIncrrctInf> [1..1]

4.1 AnyInformation <AnyInf>Presence: [1..1]This message item is part of choice 4.0 Justification.Definition: When set to yes, indicates that all available information about the underlying payment instruction shall be

sent.Data Type: One of the following YesNoIndicator values must be used:

MeaningWhenTrue: Yes



Page 201

MeaningWhenFalse: No

4.2 MissingOrIncorrectInformation <MssngOrIncrrctInf>Presence: [1..1]This message item is part of choice 4.0 Justification.Definition: Missing or incorrect information.Type: This message item is composed of the following MissingOrIncorrectInformation element(s):


4.3 MissingInformation <MssngInf> [0..10] Code

4.4 IncorrectInformation <IncrrctInf> [0..10] Code

4.3 MissingInformation <MssngInf>Presence: [0..10]Definition: Indicates the missing information.Data Type: CodeWhen this message item is present, one of the following UnableToApplyMissingInfo1Code values must be used:

Code Name DefinitionMS01 MissingRemittanceInformati

onRemittanceInformation is missing.

MS02 MissingSenderToReceiverInformation

SenderToReceiverInformation is missing.

MS03 MissingDebtor Debtor is missing.

MS04 MissingDebtorAccount DebtorAccount is missing.

MS05 MissingFirstAgent FirstAgent is missing.

MS06 MissingAmount Amount is missing.

MS07 MissingNostroVostroAccount

Nostro_VostroAccount is missing.

MS08 MissingIntermediary Intermediary is missing.

MS09 MissingReimbursementAgent1

ReimbursementAgent (53) is missing.

MS10 MissingReimbursementAgent2


MS11 MissingReimbursementAgent


MS12 MissingCreditor Creditor is missing.

MS13 MissingCreditorAccount CreditorAccount is missing.

MS14 MissingInstruction Indicates the payment instruction (MT103) is missing.



Page 202

4.4 IncorrectInformation <IncrrctInf>Presence: [0..10]Definition: Indicates the incorrect information.Data Type: CodeWhen this message item is present, one of the following UnableToApplyIncorrectInfo1Code values must be used:

Code Name DefinitionIN01 IncorrectRelatedReference RelatedReference is incorrect.

IN02 IncorrectBankOperationCode

BankOperationCode is incorrect.

IN03 IncorrectInstructionCode InstructionCode is incorrect.

IN04 IncorrectRequestedExecutionDate

RequestedExecutionDate is incorrect.

IN05 IncorrectValueDate ValueDate is incorrect.

IN06 IncorrectInterbankSettledAmount

InterbankSettledAmount is incorrect.

IN07 IncorrectDebtor Debtor is incorrect.

IN08 IncorrectDebtorAccount DebtorAccount is incorrect.

IN09 IncorrectReceiverCorrespondent

ReceiverCorrespondent is incorrect.

IN10 IncorrectThirdReimbursementInstitution

ThirdReimbursementInstitution is incorrect.

IN11 IncorrectPaymentScheme PaymentScheme is incorrect.

IN12 IncorrectAccountOfBeneficiaryInstitution

AccountOfBeneficiaryInstitution is incorrect.

IN13 IncorrectCreditor Creditor is incorrect.

IN14 IncorrectCreditorAccount CreditorAccount is incorrect.

IN15 IncorrectRemittanceInformation

RemittanceInformation is incorrect.

IN16 IncorrectPaymentPurpose PaymentPurpose is incorrect.

IN17 IncorrectDetailsOfCharges DetailsOfCharges is incorrect.

IN18 IncorrectSenderToReceiverInformation

SenderToReceiverInformation is incorrect.

IN19 IncorrectInstructionForFinalAgent

InstructionForFinalAgent is incorrect.

MM20 MismatchCreditorNameAccount

Name and Account of Creditor mismatched.

MM21 MismatchDebtorNameAccount

Name and Account of Debtor mismatched.

MM22 MismatchFinalAgentNameAccount

Name and Account of FinalAgent mismatched.



Page 203

Business Example

The following illustrates four scenarios for the UnableToApply workflow.

Narrative for Scenarios 1, 2 and 3

Customer B (BBBBGB2L) receives a statement and cannot reconcile an entry with its accounts receivables. He issues an UnableToApply message to Bank M to get more information about the entry.

Characteristics of the payment entry are as follows:

Description Value

Value Date 050523

Debit/Credit Mark C (Credit)

Amount 52317.48 GBP

Transaction Type Identification Code S103 (SWIFT Message Type 103)

Reference for the Account Owner COMPAY12345050523001

Account Servicing Institution's Reference 2005052304217018

Parties involved in scenarios 1, 2 and 3Creditor's side: Customer B (BBBBGB2L), Bank M (MMMMGB2L)Debtor's side: Customer A (AAAAGB2L), Bank C (CCCCGB2L)

Scenario 1, resulting in a RequestToCancelPayment message

Step 1Customer B asks Bank M for more information about the entry.

The following UnableToApply message is sent by Customer B to Bank M:XML Instance


<Id>UTACOMPAY12345050523001</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T08:35:30</CreDtTm>

</Assgnmt><Case>

<Id>BBBBGB2L-20050523-001</Id><Cretr>BBBBGB2L</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>COMPAY12345050523001</AssgnrInstrId><AssgneInstrId>2005052304217018</AssgneInstrId><CcyAmt Ccy="GBP">52317.48</CcyAmt>



Page 204

<ValDt>2005-05-23T00:00:00</ValDt></Undrlyg><Justfn>

<AnyInf>true</AnyInf></Justfn>

</camt.026.001.01>

Step 2Bank M assesses the UnableToApply message and looks up the original payment instruction. The original payment instruction has been received via the domestic clearing system under reference 1030123456789 and Bank M does not have additional details concerning the instruction. Therefore, Bank M forwards the UnableToApply message to Bank C (Step 2.1). Bank M also informs Customer B about the case assignment (Step 2.2).

Step 2.1The following UnableToApply message is sent by Bank M to Bank C:XML Instance


<Id>UTABBBB050523-01</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T08:52:13</CreDtTm>

</Assgnmt><Case>

<Id>20050523001</Id><Cretr>BBBBGB2L</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>2005052304217018</AssgnrInstrId><AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.026.001.01>

Step 2.2Bank M informs Customer B of the case assignment to Bank C.

The following NotificationOfCaseAssignment message is sent by Bank M to Customer B:XML Instance

<camt.030.001.01><Hdr>

<Id>CABBBB050523001</Id><Fr>MMMMGB2L</Fr><To>BBBBGB2L</To><CreDtTm>2005-05-24T08:52:44</CreDtTm>

</Hdr><Case>



Page 205


</Case><Assgnmt>

<Id>UTABBBB050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-01-27T08:52:13</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank C receives the UnableToApply message from Bank M and checks the original payment instruction. The instruction has been correctly executed. Bank C does not have additional information that would allow the customer to reconcile the payment instruction. Therefore, Bank C forwards the UnableToApply message to its ordering customer (Customer A) (Step 3.1). Bank C also informs Bank M about the case assignment (Step 3.2). Bank M informs Customer B about the case assignment to Customer A (Step 3.2).

Step 3.1Bank C forwards the UnableToApply message to Customer A. It originally received the payment instruction with reference 200505219887234.

The following UnableToApply message is sent by Bank C to Customer A:XML Instance


<Id>UTA1030123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-05-24T09:10:31</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Justfn>


</camt.026.001.01>

Step 3.2Bank C informs Bank M of the case assignment to Customer A.



Page 206

The following NotificationOfCaseAssignment message is sent by Bank C to Bank M:XML Instance

<camt.030.001.01><Hdr>

<Id>INF10301123456789</Id><Fr>CCCCGB2L</Fr><To>MMMMGB2L</To><CreDtTm>2005-05-24T09:22:44</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3.3Upon receipt of the message from Bank C , Bank M forwards the case assignment information to Customer B, for information. The following NotificationOfCaseAssignment message is sent by Bank M to Customer B: XML Instance

<camt.030.001.01><Hdr>

<Id>INFCABBBB050523001</Id><Fr>MMMMGB2L</Fr><To>BBBBGB2L</To><CreDtTm>2005-05-24T09:25:12</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>



Page 207

Step 4Upon receipt of the message from Bank C, Customer A looks up the original payment instruction. The payment instruction was not intended for Customer B and should be cancelled. Customer A initiates a cancellation request for the payment instruction to Bank C (Step 4.1). Bank C forwards the RequestToCancelPayment message to Bank M (Step 4.2). Bank M requests the debit authorisation from Customer B (Step 4.3).

Step 4.1Customer A requests the cancellation of the payment instruction.

The following RequestToCancelPayment message is sent by Customer A to Bank C:XML Instance


<Id>UTACANC10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:19:23</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Justfn>


</camt.008.002.01>

Step 4.2Bank C forwards the RequestToCancelPayment message to Bank M.

The following RequestToCancelPayment message is sent by Bank C to Bank M:XML Instance


<Id>CANC10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:22:59</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>



Page 208

<AssgnrInstrId>1030123456789</AssgnrInstrId><AssgneInstrId>20050523-04217-018</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.008.002.01>

Step 4.3Bank M requests the debit authorisation from Customer B.

The following DebitAuthorisationRequest message is sent by Bank M to Customer B:XML Instance


<Id>DARCOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:30:06</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>COMPAY12345050523001</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt><ValDt>2005-05-23T00:00:00</ValDt>

</Undrlyg><Dtl>

<CxlRsn>UPAY</CxlRsn><AmtToDbt Ccy = "GBP">52317.48</AmtToDbt>

</Dtl></camt.037.001.01>

Step 5Customer B accepts the debit request and informs Bank M (Step 5.1). Bank M will return the funds (under reference 00134789) via Bank C to Customer A (this step is not illustrated here). Bank M informs Bank C about the resolution of the investigation (Step 5.2). Bank C informs Customer A about the successful resolution of investigation (Step 5.3). The case is closed.

Step 5.1 Customer B accepts the debit request. The following DebitAuthorisationResponse message is sent by Customer B to Bank M:XML Instance


<Id>REPDARCOMPAY12345050523001</Id><Assgnr>BBBBGB2L</Assgnr>



Page 209

<Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:45:06</CreDtTm>

</Assgnmt><Case>


</Case><Conf>


</camt.036.001.01>

Step 5.2Bank M informs Bank C of the positive debit authorisation received from Customer B.

The following ResolutionOfInvestigation message is sent by Bank M to Bank C:XML Instance


<Id>CONFCANC10301123456789</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:53:07</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 5.3 Bank C informs Customer A of the successful resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank C to Customer A:XML Instance


<Id>CONFCANC10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>AAAAGB2L</Assgne><CreDtTm>2005-05-24T11:58:13</CreDtTm>



</RslvdCase><Sts>

<Conf>ACDA</Conf>



Page 210

</Sts></camt.029.001.01>

Scenario 2, resulting in an AdditionalPaymentInformation message The initial steps of this scenario (Steps 1, 2 and 3) replicate those described in scenario 1 above. Therefore the description of this scenario starts at Step 4, when Customer A provides additional payment information for Customer B to reconcile the payment entry.

Step 4Customer A provides additional payment information to Bank C in response to the UnabletoApply message. The payment has been made based on an invoice in euro, but paid in GBP, and the initiator of the invoice is the French subsidiary of Customer B.

The following AdditionalPaymentInformation message is sent by Bank A to Bank C:XML Instance


<Id>UTAINFO10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:25:32</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Inf>

<RmtChc><Ustrd>/INV/20050301/</Ustrd>

</RmtChc><Amt>

<InstdAmt Ccy = "EUR">75680.35</InstdAmt></Amt><Cdtr>

<Nm>Customer B</Nm><Id>

<OrgId><EANGLN>7265658971233</EANGLN>

</OrgId></Id>

</Cdtr></Inf>

</camt.028.001.01>



Page 211

Step 5 Bank C forwards the AdditionalPaymentInformation message to Bank M (Step 5.1) for further transmission to Customer B (Step 5.2). The additional information allows Customer B to reconcile the entry. The case is closed.

Step 5.1Bank C sends the additional payment information to Bank M.

The following AdditionalPaymentInformation message is sent by Bank C to Bank M:XML Instance


<Id>UTABBBB050523001INFO</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:27:54</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Inf>


</RmtChc><Amt>




</OrgId></Id>

</Cdtr></Inf>

</camt.028.001.01>

Step 5.2Bank M forwards the AdditionalPaymentInformation message to Customer B. The reconciliation is successful and the case is closed.

The following AdditionalPaymentInformation message is sent by Bank M to Customer B:XML Instance



Page 212


<Id>REPUTACOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:45:04</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>


</Undrlyg><Inf>


</RmtChc><Amt>




</OrgId></Id>

</Cdtr></Inf>

</camt.028.001.01>

Scenario 3, resulting in a RequestForModification messageThe initial steps of this scenario (Steps 1, 2 and 3) replicate those described in scenario 1 above. Therefore, the description of this scenario starts at Step 4, when Customer A requests the modification of the payment instruction to Bank C.

Step 4Customer A decides to request the modification of the original payment instruction. The original payment instruction did not contain the remittance information which referenced the invoices settled by the payment. The remittance information should have referenced two commercial invoices: /INV/20050512/GBP23257./20050500104712//20050513/29060.48/20050100204712/Customer A requests the modification of the payment instruction (Step 4.1). Bank C forwards the modification request to Bank M (Step 4.2).

Step 4.1 The following RequestToModifyPayment message is sent by Customer A to Bank C:XML Instance



Page 213


<Id>UTAMODI10301123456789</Id><Assgnr>AAAAGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T11:25:32</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>

Step 4.2Bank C forwards the request for modification to Bank M.

The following RequestToModifyPayment message is sent by Bank C to Bank M:XML Instance


<Id>UTAMODI10301123456789</Id><Assgnr>CCCCGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:29:44</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>1030123456789</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>



Page 214

Step 5Upon receipt of the RequestToModifyPayment message, Bank M looks up the original payment instruction. There is no impact on the accounting entries made for this payment instruction and it has been correctly executed. Bank M forwards the request for modification to Customer B.

The following RequestToModifyPayment message is sent by Bank M to Customer B:XML Instance


<Id>MODICOMPAY12345050523001</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>BBBBGB2L</Assgne><CreDtTm>2005-05-24T11:35:42</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgneInstrId>COMPAY12345050523001</AssgneInstrId><CcyAmt Ccy = "GBP">52317.48</CcyAmt>

</Undrlyg><Mod>


</RmtInf></Mod>

</camt.007.002.01>

Step 6The RequestToModifyPayment message received by Customer B allows reconciliation with its accounts receivables. Customer B closes the case and informs Bank M of the case resolution (Step 6.1). Bank M informs Bank C about the case resolution (Step 6.2). Bank C then informs Customer A of the case resolution (Step 6.3).

Step 6.1 Customer B informs Bank M of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Customer B to Bank M:XML Instance


<Id>CONFMODICOMPAY1234505052301</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>MMMMGB2L</Assgne><CreDtTm>2005-05-24T11:58:13</CreDtTm>



</RslvdCase>



Page 215

<Sts><Conf>MODI</Conf>

</Sts></camt.029.001.01>

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

The following ResolutionOfInvestigation message is sent by Bank M to Bank C:XML Instance


<Id>CONFUTAMODI10301123456789</Id><Assgnr>MMMMGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T12:34:22</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Step 6.3Bank B informs Bank C of the resolution of the case.

The following ResolutionOfInvestigation message is sent by Bank B to Bank C:XML Instance


<Id>CONFUTAMODI10301123456789</Id><Assgnr>BBBBGB2L</Assgnr><Assgne>CCCCGB2L</Assgne><CreDtTm>2005-05-24T12:43:58</CreDtTm>



</RslvdCase><Sts>


</camt.029.001.01>

Scenario 4The following illustrates the fourth scenario for the UnableToApply workflow. This scenario corresponds to a missing instruction case, ie, an agent has received a cover payment (MT 202) which cannot be reconciled with a pending instruction



Page 216

to process (eg, an MT 103). The resolution of the investigation below relies upon the first agent issuing the missing payment instruction (eg, MT 103). The issuance of the payment instruction is not illustrated as it is outside the scope of the Exceptions and Investigations messages workflow.

NarrativeBank B, Munich (BBBBDEMM) receives the following statement line from its euro clearing institution (Bank D, Frankfurt DDDDDEFF).

Characteristics of the statement entry are as follows:

Description Value

Value Date 050116

Debit/Credit Mark C (Credit)

Amount 12439.57 EUR

Transaction Type Identification Code S202 (SWIFT Message Type 202)

Reference for the account owner 1239876540123 (this corresponds to the content of field 21 of the MT 202 instruction)

Account Servicing Institution's Reference 2005011602312003

Step 1 Bank B investigates the entry and cannot reconcile based on the elements attached to the entry. Bank B decides to request clarification to its account servicing institution (Bank D) using an UnableToApply message.

The following UnableToApply message is sent by Bank B to Bank D:XML Instance


<Id>UTA1239876540123050116</Id><Assgnr>BBBBDEMM</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-01-16T08:35:30</CreDtTm>

</Assgnmt><Case>

<Id>1239876540123050116001</Id><Cretr>BBBBDEMM</Cretr>

</Case><Undrlyg>

<AssgnrInstrId>1239876540123</AssgnrInstrId><AssgneInstrId>2005011602312003</AssgneInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.026.001.01>



Page 217

Step 2Bank D looks up the original MT 202 instruction. The sender was Bank U, New York (UUUUUS33). The MT 202 contained reference 123458760501 (equivalent of field 20 of the MT 202). Bank D forwards the UnableToApply message to Bank U (Step 2.1) and informs Bank B of the case assignment to Bank U (Step 2.2).

Step 2.1Bank D forwards the UnableToApply to Bank U.

The following UnableToApply message is sent by Bank D to Bank U:XML Instance


<Id>UTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T08:44:23</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>2005011602312003</AssgnrInstrId><AssgneInstrId>123458760501</AssgneInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.026.001.01>

Step 2.2Bank D informs Bank B of the case assignment to Bank U.

The following NotificationOfCaseAssignment message is sent by Bank D to Bank B:XML Instance

<camt.030.001.01><Hdr>

<Id>REPUTA1239876540123050116</Id><Fr>DDDDDEFF</Fr><To>BBBBDEMM</To><CreDtTm>2005-01-16T08:48:30</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>



Page 218

<Id>UTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T08:44:23</CreDtTm>

</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3Bank U received the MT 202 instruction from Bank Z, New York (ZZZZUS33). The transfer was correctly executed. Bank U forwards the UnableToApply message to Bank Z for further information (Step 3.1). Bank U also informs Bank D that the case has been forwarded (Step 3.2). Bank D informs Bank B of the case assignment to Bank Z (Step 3.3).

Step 3.1Bank U asks Bank Z to investigate.

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


<Id>FWUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>ZZZZUS33</Assgne><CreDtTm>2005-01-16T09:02:45</CreDtTm>

</Assgnmt><Case>


</Case><Undrlyg>

<AssgnrInstrId>123458760501</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>

</Undrlyg><Justfn>


</camt.026.001.01>

Step 3.2Bank U informs Bank D of the case assignment to Bank Z.

The following NotificationOfCaseAssignment message is sent by Bank U to Bank D:XML Instance

<camt.030.001.01><Hdr>

<Id>INFOUTA1239876540123050116</Id><Fr>UUUUUS33</Fr><To>DDDDDEFF</To>



Page 219

<CreDtTm>2005-01-16T09:05:43</CreDtTm></Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 3.3 Bank D informs Bank B of the case assignment to Bank Z.

The following NotificationOfCaseAssignment message is sent by Bank D to Bank B:XML Instance

<camt.030.001.01><Hdr>

<Id>FUREPUTA1239876540123050116</Id><Fr>DDDDDEFF</Fr><To>BBBBDEMM</To><CreDtTm>2005-01-16T09:13:23</CreDtTm>

</Hdr><Case>


</Case><Assgnmt>


</Assgnmt><Ntfctn>


</camt.030.001.01>

Step 4Bank Z looks up the original MT 202. The message was sent as a cover to an MT 103 instruction. However, while reconciling the MT 103 instruction, it appears that it had been rejected. The reason code for rejection was beneficiary's account number missing. In the meantime, the payment instruction has been issued again under reference CORR1239876540123. The new payment instruction requests a back valuation (the value date is equivalent to the original value date).



Page 220

Bank Z informs Bank U that the case can be closed (Step 4.1) and indicates the new reference for the corrected transaction. Bank U informs Bank D (Step 4.2). Bank D informs Bank B (Step 4.3) that the investigation has been resolved.

Step 4.1Bank Z informs Bank U that the case can be closed.

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


<Id>ENDFWUTA1239876540123050116</Id><Assgnr>ZZZZUS33</Assgnr><Assgne>UUUUUS33</Assgne><CreDtTm>2005-01-16T11:03:48</CreDtTm>


<Id>1239876540123050116001</Id><Cretr>DDDDDEMM</Cretr>

</RslvdCase><Sts>

<Conf>IPYI</Conf></Sts><CrrctnTx>

<AssgnrInstrId>CORR1239876540123</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>


Step 4.2Bank U forwards the information to Bank D.

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


<Id>CLOSEUTA1239876540123050116</Id><Assgnr>UUUUUS33</Assgnr><Assgne>DDDDDEFF</Assgne><CreDtTm>2005-01-16T11:25:46</CreDtTm>


<Id>1239876540123050116001</Id><Cretr>DDDDDEMM</Cretr>

</RslvdCase><Sts>


<AssgnrInstrId>CORR1239876540123</AssgnrInstrId>



Page 221



Step 4.3Bank D forwards the resolution of investigation information to Bank B.

The following ResolutionOfInvestigation message is sent by Bank D to Bank B:XML Instance


<Id>CLOSEUTA1239876540123050116</Id><Assgnr>DDDDDEFF</Assgnr><Assgne>BBBBDEMM</Assgne><CreDtTm>2005-01-16T11:34:26</CreDtTm>



</RslvdCase><Sts>


<AssgnrInstrId>CORR1239876540123</AssgnrInstrId><CcyAmt Ccy = "EUR">12439.57</CcyAmt><ValDt>2005-01-16T00:00:00</ValDt>




Page 222

Message Item TypesData TypesData Types Index

1 Amount1.1 CurrencyAndAmount1.2 ImpliedCurrencyAndAmount

2 Date Time2.1 ISODate2.2 ISODateTime

3 Identifier3.1 AnyBICIdentifier3.2 AustrianBankleitzahlIdentifier3.3 BBANIdentifier3.4 BEIIdentifier3.5 BICIdentifier3.6 CHIPSParticipantIdentifier3.7 CHIPSUniversalIdentifier3.8 CanadianPaymentsARNIdentifier3.9 CountryCode3.10 CurrencyCode3.11 DunsIdentifier3.12 EANGLNIdentifier3.13 ExtensiveBranchNetworkIdentifier3.14 FedwireRoutingNumberIdentifier3.15 GermanBankleitzahlIdentifier3.16 HongKongBankIdentifier3.17 IBANIdentifier3.18 IrishNSCIdentifier3.19 ItalianDomesticIdentifier3.20 LanguageCode3.21 MICIdentifier3.22 NationalityCode3.23 NewZealandNCCIdentifier3.24 PortugueseNCCIdentifier3.25 RussianCentralBankIdentificationCodeIdentifier3.26 SmallNetworkIdentifier3.27 SouthAfricanNCCIdentifier3.28 SpanishDomesticInterbankingIdentifier3.29 SwissBCIdentifier3.30 SwissSICIdentifier3.31 UKDomesticSortCodeIdentifier3.32 UPICIdentifier

4 Quantity: Number and Decimal Number4.1 Number


Message Item Types

Page 223

5 Rate5.1 PercentageRate

6 Text6.1 Max10Text6.2 Max128Text6.3 Max140Text6.4 Max16Text6.5 Max256Text6.6 Max350Text6.7 Max35Text6.8 Max70Text

Data Types Description

1 Amount

1.1 CurrencyAndAmount

Definition: Number of monetary units specified in a currency, where the unit of currency is explicit and compliant with ISO 4217. The decimal separator is a dot.Note: A zero amount is considered a positive amount.

XML Attribute: Currency (Ccy). This XML Attribute is typed by CurrencyCode.Format: CurrencyAndAmount



Example: 100000 (Ccy='EUR')

1.2 ImpliedCurrencyAndAmount

Definition: Number of monetary units specified in a currency where the unit of currency is implied by the context and compliant with ISO 4217. The decimal separator is a dot.Note: a zero amount is considered a positive amount.

Format: fractionDigits: 5minInclusive: 0totalDigits: 18

Example: 500000

2 Date Time

2.1 ISODate

Definition: Date within a particular calendar year represented by YYYY-MM-DD (ISO 8601).

Example: 2002-02-25


Message Item Types

Page 224

2.2 ISODateTime

Definition: Date and time within a particular calendar year represented by YYYY-MM-DDThh :mm :ss (ISO 8601).

Example: 2002-07-21T08:35:30

3 Identifier

3.1 AnyBICIdentifier

Definition: A code allocated to a business entity or to a financial institution by a Registration Authority under an international identification scheme, as described in the latest edition of the international standard ISO 9362 "Banking - Banking telecommunication messages - Bank identifier codes".

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

Rule(s): AnyBICRule Only a valid BIC or BEI is allowed. Valid BEI and BIC are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.

Example: CHASUS33

3.2 AustrianBankleitzahlIdentifier

Definition: Austrian Bankleitzahl. Identifies Austrian financial institutions on the Austrian national clearing system.

Format: AT[0-9]{5,5}

Example: AT12345

3.3 BBANIdentifier

Definition: Basic Bank Account Number (BBAN). Identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), which uniquely identifies the account of a customer.

Format: [a-zA-Z0-9]{1,30}

Example: BARC12345612345678

3.4 BEIIdentifier

Definition: Business Entity Identifier. Code allocated to non-financial institutions by the ISO 9362 Registration Authority. The Business Entity Identifier (BEI) has the same format as the BIC code (8 up to 11 characters) as stipulated in the standard ISO 9362 Banking (Banking Telecommunication Messages, Bank Identifier Codes, BIC).


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


Message Item Types

Page 225

following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE, are valid BEIs.

Example: USINFRPP

3.5 BICIdentifier

Definition: Bank Identifier Code. code allocated to a financial institution by a Registration Authority under an international identification scheme, as described in the latest edition of the international standard ISO 9362 "Banking - Banking telecommunication messages - Bank identifier codes".


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


Message Item Types

Page 226

Format: [A-Z]{2,2}

Rule(s): Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).

Example: BE

3.10 CurrencyCode

Definition: Code allocated to a currency, by a maintenance agency, under an international identification scheme as described in the latest edition of the international standard ISO 4217 "Codes for the representation of currencies and funds". Valid currency codes are registered with the ISO 4217 Maintenance Agency, and consist of three contiguous letters.

Format: [A-Z]{3,3}

Rule(s): ValidationByTable

Example: AWG

3.11 DunsIdentifier

Definition: Data Universal Numbering System. A unique identification number provided by Dun & Bradstreet to identify an organization.

Format: [0-9]{9,9}

Example: 578942538

3.12 EANGLNIdentifier

Definition: Global Location Number. A non-significant reference number used to identify legal entities, functional entities or physical entities according to the European Association for Numbering (EAN) numbering scheme rules. The number is used to retrieve the detailed information linked to it.

Format: [0-9]{13,13}

Example: 7265658971233

3.13 ExtensiveBranchNetworkIdentifier

Definition: The extensive branch network list of the Australian Bank State Branch (BSB) Code. The codes are used for identifying Australian financial institutions, as assigned by the Australian Payments Clearing Association (APCA).

Format: AU[0-9]{6,6}

Example: AU123456

3.14 FedwireRoutingNumberIdentifier

Definition: Fedwire Routing Number. Identifies financial institutions, in the US, on the FedWire system. The routing number is assigned by the American Bankers Association (ABA).

Format: FW[0-9]{9,9}

Example: FW123456789


Message Item Types

Page 227

3.15 GermanBankleitzahlIdentifier

Definition: German Bankleitzahl. Identifies German financial institutions on the German national clearing systems.

Format: BL[0-9]{8,8}

Example: BL12345678

3.16 HongKongBankIdentifier

Definition: Hong Kong Bank Code. Identifies Hong Kong financial institutions on the Hong Kong local clearing system.

Format: HK[0-9]{3,3}

Example: HK123

3.17 IBANIdentifier

Definition: An identifier used internationally by financial institutions to uniquely identify the account of a customer at a financial institution, as described in the latest edition of the international standard ISO 13616. "Banking and related financial services - International Bank Account Number (IBAN)".

Format: [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}

Rule(s): IBAN A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.

Example: AT611904300234573201

3.18 IrishNSCIdentifier

Definition: Irish National Sorting Code. Identifies Irish financial institutions on the Irish national clearing system.

Format: IE[0-9]{6,6}

Example: IE123456

3.19 ItalianDomesticIdentifier

Definition: Italian Domestic Identification Code. Identifies Italian financial institutions on the Italian national clearing system. The code is assigned by the Associazione Bancaria Italiana (ABI).

Format: IT[0-9]{10,10}

Example: IT1234567890

3.20 LanguageCode

Definition: Specifies a language.


Example: ENG


Message Item Types

Page 228

3.21 MICIdentifier

Definition: Market Identifier Code. The identification of a financial market, as stipulated in the norm ISO 10383 'Codes for exchanges and market identifications'.

Format: [A-Z0-9]{4,4}

Example: XTKS

3.22 NationalityCode

Definition: Specifies the country where a person was born or is naturalised.


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}


Message Item Types

Page 229

Example: ZA123456

3.28 SpanishDomesticInterbankingIdentifier

Definition: Spanish Domestic Interbanking Code. Identifies Spanish financial institutions on the Spanish national clearing system. The code is assigned by the Centro de Cooperacion Interbancaria (CCI).

Format: ES[0-9]{8,9}

Example: ES12345678

3.29 SwissBCIdentifier

Definition: Swiss Bank Code. Identifies Swiss institutions on the Swiss national clearing system.

Format: SW[0-9]{3,5}

Example: SW123

3.30 SwissSICIdentifier

Definition: Swiss Interbank Clearing (SIC) Code. Identifies Swiss financial institutions domestically, on the Swiss national clearing system.

Format: SW[0-9]{6,6}

Example: SW123456

3.31 UKDomesticSortCodeIdentifier

Definition: United Kingdom (UK) Sort Code. Identifies British financial institutions on the British national clearing systems. The sort code is assigned by the Association for Payments and Clearing Services (APACS).

Format: SC[0-9]{6,6}

Example: SC123456

3.32 UPICIdentifier

Definition: Universal Payment Identification Code (UPIC). Identifier used by the New York Clearing House to mask confidential data, such as bank accounts and bank routing numbers. UPIC numbers remain with business customers, regardless of banking relationship changes.

Format: [0-9]{8,17}

Example: 12345678

4 Quantity: Number and Decimal Number

4.1 Number

Definition: Number of objects represented as an integer.

Format: fractionDigits: 0totalDigits: 18

Example: 123456789012345678


Message Item Types

Page 230

5 Rate

5.1 PercentageRate

Definition: Rate expressed as a percentage, ie, in hundredths, eg, 0.7 is 7/10 of a percent, and 7.0 is 7%.

Format: fractionDigits: 10totalDigits: 11

Example: 35

6 Text

6.1 Max10Text

Definition: Specifies a character string with a maximum length of 10 characters.


Example: AZERTGFDXC

6.2 Max128Text



Example: A string value of maximum 128 characters.

6.3 Max140Text



Example: ABCDEFGHIJKLMNOPQRST123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

6.4 Max16Text



Example: ABCdEFghIJKLMNO?

6.5 Max256Text





Message Item Types

Page 231

6.6 Max350Text



Example: 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

6.7 Max35Text




6.8 Max70Text

Definition: Specifies a character string with a maximum length of 70characters.


Example: A string value of maximum 70 characters.

End PointsEnd Points Index

1 Account identification1.1 CashAccount3

2 Financial institution identification2.1 BranchAndFinancialInstitutionIdentification

3 Party identification3.1 Intermediary13.2 PartyIdentification1

End Points Description

1 Account identification

1.1 CashAccount3CashAccount3 is used in message AdditionalPaymentInformation p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156, p.156.

Definition: Information used for identifying an account.


Message Item Types

Page 232

Type: The following CashAccount3 element(s) must be used:

Ref Or Message Item <XML Tag> Mult. Represent./Type

1.1.0 Identification <Id> [1..1]

1.1.1 {Or IBAN <IBAN> [1..1] Identifier

1.1.2 Or BBAN <BBAN> [1..1] Identifier

1.1.3 Or UPIC <UPIC> [1..1] Identifier

1.1.4 Or} DomesticAccount <DmstAcct> [1..1]

1.1.5 Identification <Id> [1..1] Text

1.1.6 Type <Tp> [0 ..1] Code

1.1.7 Currency <Ccy> [0..1] Code

1.1.8 Name <Nm> [0..1] Text

1.1.0 Identification <Id>Presence: [1..1]Definition: Unique and unambiguous identification of the account between the account owner and the account servicer.Type: This message item is composed of one of the following AccountIdentification1Choice element(s):


1.1.1 {Or IBAN <IBAN> [1..1] Identifier

1.1.2 Or BBAN <BBAN> [1..1] Identifier

1.1.3 Or UPIC <UPIC> [1..1] Identifier

1.1.4 Or} DomesticAccount <DmstAcct> [1..1]

1.1.1 IBAN <IBAN>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: International Bank Account Number (IBAN) - identifier used internationally by financial institutions to

uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found in the standard ISO 13616 "Banking and related financial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions.

Data Type: IBANIdentifierFormat: [a-zA-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30}Rule(s): IBAN

A valid IBAN consists of all three of the following components: Country Code, check digits and BBAN.

1.1.2 BBAN <BBAN>Presence: [1..1]This message item is part of choice 1.1.0 Identification.


Message Item Types

Page 233

Definition: Basic Bank Account Number (BBAN) - identifier used nationally by financial institutions, ie, in individual countries, generally as part of a National Account Numbering Scheme(s), to uniquely identify the account of a customer.

Data Type: BBANIdentifierFormat: [a-zA-Z0-9]{1,30}

1.1.3 UPIC <UPIC>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: Universal Payment Identification Code (UPIC) - identifier used by the New York Clearing House to mask

confidential data, such as bank accounts and bank routing numbers. UPIC numbers remain with business customers, regardless of banking relationship changes.

Data Type: UPICIdentifierFormat: [0-9]{8,17}

1.1.4 DomesticAccount <DmstAcct>Presence: [1..1]This message item is part of choice 1.1.0 Identification.Definition: Account number used by financial institutions in individual countries to identify an account of a customer,

but not necessarily the bank and branch of the financial institution in which the account is held.Type: This message item is composed of the following SimpleIdentificationInformation element(s):



1.1.5 Identification <Id>Presence: [1..1]Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

1.1.6 Type <Tp>Presence: [0 ..1]Definition: Nature, or use, of the account.Data Type: CodeWhen this message item is present, one of the following CashAccountType3Code values must be used:

Code Name DefinitionCACC Current Account used to post debits and credits when no specific

account has been nominated.

CASH CashPayment Account used for the payment of cash.

CHAR Charges Account used for charges if different from the account for payment.


Message Item Types

Page 234

Code Name DefinitionSACC Settlement Account used to post debit and credit entries, as a result of

transactions cleared and settled through a specific clearing and settlement system.

SVGS Savings Account used for savings.

1.1.7 Currency <Ccy>Presence: [0..1]Definition: Identification of the currency in which the debtor's account is held.

Usage: Currency should only be used in case one and the same debtor's account number covers several currencies and the initiating party needs to identify which currency needs to be used for settlement on the account.

Data Type: CurrencyCodeFormat: [A-Z]{3,3}Rule(s): ValidationByTable

1.1.8 Name <Nm>Presence: [0..1]Definition: Name of the account, assigned by the account servicing institution in agreement with the account owner in

order to provide an additional means of identification of the account.

Usage : the account name is different from the account owner name. The account name is used in certain user communities to provide a means of identifying the account, in addition to the account owner's identity and the account number.


minLength: 1

2 Financial institution identification

2.1 BranchAndFinancialInstitutionIdentificationBranchAndFinancialInstitutionIdentification is used in message AdditionalPaymentInformation p.30, p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156.

Definition: Organisation established primarily to provide financial services.Type: The following BranchAndFinancialInstitutionIdentification element(s) must be used:


2.1.0 FinancialInstitutionIdentification <FinInstnId> [1..1]

2.1.1 BIC <BIC> [0..1] Identifier

2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId> [0..1]

2.1.3 {Or CHIPSUniversalIdentification <USCHU> [1..1] Identifier

2.1.4 Or NewZealandNCCIdentification <NZNCC> [1..1] Identifier


Message Item Types

Page 235


2.1.5 Or IrishNSCIdentification <IENSC> [1..1] Identifier

2.1.6 Or UKDomesticSortCode <GBSC> [1..1] Identifier

2.1.7 Or CHIPSParticipantIdentification <USCH> [1..1] Identifier

2.1.8 Or SwissBCIdentification <CHBC> [1..1] Identifier

2.1.9 Or FedwireRoutingNumberIdentification <USFW> [1..1] Identifier

2.1.10 Or PortugueseNCCIdentification <PTNCC> [1..1] Identifier

2.1.11 Or RussianCentralBankIdentificationCode <RUCB> [1..1] Identifier

2.1.12 Or ItalianDomesticIdentificationCode <ITNCC> [1..1] Identifier

2.1.13 Or AustrianBankleitzahlIdentification <ATBLZ> [1..1] Identifier

2.1.14 Or CanadianPaymentsAssociationRoutingNumberIdentification

<CACPA> [1..1] Identifier

2.1.15 Or SwissSICIdentification <CHSIC> [1..1] Identifier

2.1.16 Or GermanBankleitzahlIdentification <DEBLZ> [1..1] Identifier

2.1.17 Or SpanishDomesticInterbankingIdentification

<ESNCC> [1..1] Identifier

2.1.18 Or SouthAfricanNCCIdentification <ZANCC> [1..1] Identifier

2.1.19 Or HongKongBankCode <HKNCC> [1..1] Identifier

2.1.20 Or AustralianExtensiveBranchNetworkIdentification

<AUBSBx> [1..1] Identifier

2.1.21 Or} AustralianSmallNetworkIdentification <AUBSBs> [1..1] Identifier

2.1.22 Name <Nm> [0..1] Text

2.1.23 PostalAddress <PstlAdr> [0..1]

2.1.24 AddressType <AdrTp> [0..1] Code

2.1.25 AddressLine <AdrLine> [0..5] Text

2.1.26 StreetName <StrtNm> [0..1] Text

2.1.27 BuildingNumber <BldgNb> [0..1] Text

2.1.28 PostCode <PstCd> [0..1] Text

2.1.29 TownName <TwnNm> [0..1] Text

2.1.30 CountrySubDivision <CtrySubDvsn> [0..1] Text

2.1.31 Country <Ctry> [1..1] Code

2.1.32 ProprietaryIdentification <PrtryId> [0..1]


2.1.34 Issuer <Issr> [0..1] Text

2.1.35 BranchIdentification <BrnchId> [0..1]


2.1.37 Name <Nm> [0..1] Text


Message Item Types

Page 236











2.1.0 FinancialInstitutionIdentification <FinInstnId>Presence: [1..1]Definition: Unique and unambiguous identifier of a financial institution, as assigned under an internationally recognised

or proprietary identification scheme.Type: This message item is composed of the following FinancialInstitutionIdentification1 element(s):


2.1.1 BIC <BIC> [0..1] Identifier

2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId> [0..1]

2.1.22 Name <Nm> [0..1] Text



2.1.1 BIC <BIC>Presence: [0..1]Definition: Bank Identifier Code. Code allocated to financial institutions by the Registration Authority, under an

international identification scheme, as described in the latest version of the standard ISO 9362 Banking (Banking telecommunication messages, Bank Identifier Codes).

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

Valid BICs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE. The bank code, country code and location code are mandatory, while the branch code is optional.

2.1.2 ClearingSystemMemberIdentification <ClrSysMmbId>Presence: [0..1]


Message Item Types

Page 237

Definition: Unique and unambiguous identifier of a clearing system member, as assigned by the system or system administrator.

Type: This message item is composed of one of the following ClearingSystemMemberIdentificationChoice element(s):


2.1.3 {Or CHIPSUniversalIdentification <USCHU> [1..1] Identifier

2.1.4 Or NewZealandNCCIdentification <NZNCC> [1..1] Identifier

2.1.5 Or IrishNSCIdentification <IENSC> [1..1] Identifier

2.1.6 Or UKDomesticSortCode <GBSC> [1..1] Identifier

2.1.7 Or CHIPSParticipantIdentification <USCH> [1..1] Identifier

2.1.8 Or SwissBCIdentification <CHBC> [1..1] Identifier

2.1.9 Or FedwireRoutingNumberIdentification <USFW> [1..1] Identifier

2.1.10 Or PortugueseNCCIdentification <PTNCC> [1..1] Identifier

2.1.11 Or RussianCentralBankIdentificationCode <RUCB> [1..1] Identifier

2.1.12 Or ItalianDomesticIdentificationCode <ITNCC> [1..1] Identifier

2.1.13 Or AustrianBankleitzahlIdentification <ATBLZ> [1..1] Identifier

2.1.14 Or CanadianPaymentsAssociationRoutingNumberIdentification

<CACPA> [1..1] Identifier

2.1.15 Or SwissSICIdentification <CHSIC> [1..1] Identifier

2.1.16 Or GermanBankleitzahlIdentification <DEBLZ> [1..1] Identifier

2.1.17 Or SpanishDomesticInterbankingIdentification <ESNCC> [1..1] Identifier

2.1.18 Or SouthAfricanNCCIdentification <ZANCC> [1..1] Identifier

2.1.19 Or HongKongBankCode <HKNCC> [1..1] Identifier

2.1.20 Or AustralianExtensiveBranchNetworkIdentification

<AUBSBx> [1..1] Identifier

2.1.21 Or} AustralianSmallNetworkIdentification <AUBSBs> [1..1] Identifier

2.1.3 CHIPSUniversalIdentification <USCHU>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: (United States) Clearing House Interbank Payments System (CHIPS) Universal Identification (UID) -

identifies entities that own accounts at CHIPS participating financial institutions, through which CHIPS payments are effected. The CHIPS UID is assigned by the New York Clearing House.

Data Type: CHIPSUniversalIdentifierFormat: CH[0-9]{6,6}

2.1.4 NewZealandNCCIdentification <NZNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: New Zealand Bank/Branch Code - identifies New Zealand institutions on the New Zealand national clearing

system. The code is assigned by the New Zealand Bankers' Association (NZBA).


Message Item Types

Page 238

Data Type: NewZealandNCCIdentifierFormat: NZ[0-9]{6,6}

2.1.5 IrishNSCIdentification <IENSC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Irish National Sorting Code - identifies Irish financial institutions on the Irish national clearing system. The

code is assigned by the Irish Payments Services Organisation (IPSO).Data Type: IrishNSCIdentifierFormat: IE[0-9]{6,6}

2.1.6 UKDomesticSortCode <GBSC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: United Kingdom (UK) Sort Code - identifies British financial institutions on the British national clearing

systems. The sort code is assigned by the Association for Payments and Clearing Services (APACS).Data Type: UKDomesticSortCodeIdentifierFormat: SC[0-9]{6,6}

2.1.7 CHIPSParticipantIdentification <USCH>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: (United States) Clearing House Interbank Payment System (CHIPS) Participant Identifier (ID) - identifies

financial institutions participating on CHIPS. The CHIPS Participant ID is assigned by the New York Clearing House.

Data Type: CHIPSParticipantIdentifierFormat: CP[0-9]{4,4}

2.1.8 SwissBCIdentification <CHBC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Swiss Bank Code - identifies Swiss institutions on the Swiss national clearing system.Data Type: SwissBCIdentifierFormat: SW[0-9]{3,5}

2.1.9 FedwireRoutingNumberIdentification <USFW>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Fedwire Routing Number - identifies financial institutions, in the US, on the FedWire system. The routing

number is assigned by the American Bankers Association (ABA).Data Type: FedwireRoutingNumberIdentifierFormat: FW[0-9]{9,9}

2.1.10 PortugueseNCCIdentification <PTNCC>Presence: [1..1]


Message Item Types

Page 239

This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Portuguese National Clearing Code - identifies Portuguese financial institutions on the Portuguese national

clearing system.Data Type: PortugueseNCCIdentifierFormat: PT[0-9]{8,8}

2.1.11 RussianCentralBankIdentificationCode <RUCB>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Russian Central Bank Identification Code - identifies Russian financial institutions on the Russian national

clearing system.Data Type: RussianCentralBankIdentificationCodeIdentifierFormat: RU[0-9]{9,9}

2.1.12 ItalianDomesticIdentificationCode <ITNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Italian Domestic Identification Code - identifies Italian financial institutions on the Italian national clearing

system. The code is assigned by the Associazione Bancaria Italiana (ABI).Data Type: ItalianDomesticIdentifierFormat: IT[0-9]{10,10}

2.1.13 AustrianBankleitzahlIdentification <ATBLZ>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Austrian Bankleitzahl - identifies Austrian financial institutions on the Austrian national clearing system.Data Type: AustrianBankleitzahlIdentifierFormat: AT[0-9]{5,5}

2.1.14 CanadianPaymentsAssociationRoutingNumberIdentification <CACPA>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Canadian Payments Association Routing Number - identifies Canadian financial institutions on the Canadian

national clearing system.Data Type: CanadianPaymentsARNIdentifierFormat: CA[0-9]{9,9}

2.1.15 SwissSICIdentification <CHSIC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Swiss Interbank Clearing (SIC) Code - identifies Swiss financial institutions domestically, on the Swiss

national clearing system.Data Type: SwissSICIdentifierFormat: SW[0-9]{6,6}


Message Item Types

Page 240

2.1.16 GermanBankleitzahlIdentification <DEBLZ>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: German Bankleitzahl - identifies German financial institutions on the German national clearing systems.Data Type: GermanBankleitzahlIdentifierFormat: BL[0-9]{8,8}

2.1.17 SpanishDomesticInterbankingIdentification <ESNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Spanish Domestic Interbanking Code - identifies Spanish financial institutions on the Spanish national

clearing system. The code is assigned by the Centro de Cooperacion Interbancaria (CCI).Data Type: SpanishDomesticInterbankingIdentifierFormat: ES[0-9]{8,9}

2.1.18 SouthAfricanNCCIdentification <ZANCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: South African National Clearing Code (NCC) - identifies South African financial institutions on the South

African national clearing system. The code is assigned by the South African Bankers Services Company Ltd. (BankServ).

Data Type: SouthAfricanNCCIdentifierFormat: ZA[0-9]{6,6}

2.1.19 HongKongBankCode <HKNCC>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Hong Kong Bank Code - identifies Hong Kong financial institutions on the Hong Kong local clearing system.Data Type: HongKongBankIdentifierFormat: HK[0-9]{3,3}

2.1.20 AustralianExtensiveBranchNetworkIdentification <AUBSBx>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Extensive branch network list of the Australian Bank State Branch (BSB) Code. The codes are used for

identifying Australian financial institutions, as assigned by the Australian Payments Clearing Association (APCA).

Data Type: ExtensiveBranchNetworkIdentifierFormat: AU[0-9]{6,6}

2.1.21 AustralianSmallNetworkIdentification <AUBSBs>Presence: [1..1]This message item is part of choice 2.1.2 ClearingSystemMemberIdentification.Definition: Small network list of the Australian Bank State Branch (BSB) Code. The codes are used for identifying

Australian financial institutions , as assigned by the Australian Payments Clearing Association (APCA).


Message Item Types

Page 241

Data Type: SmallNetworkIdentifierFormat: AU[0-9]{6,6}

2.1.22 Name <Nm>Presence: [0..1]Definition: Name by which a party is known and which is usually used to identify that party.Data Type: Max70TextFormat: maxLength: 70

minLength: 1

2.1.23 PostalAddress <PstlAdr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of the following PostalAddress1 element(s):










2.1.24 AddressType <AdrTp>Presence: [0..1]Definition: Identifies the nature of the postal address.Data Type: CodeWhen this message item is present, one of the following AddressType2Code values must be used:

Code Name DefinitionADDR Postal Address is the complete postal address.

BIZZ Business Address is the business address.

DLVY DeliveryTo Address is the address to which delivery is to take place.

HOME Residential Address is the home address.

MLTO MailTo Address is the address to which mail is sent.

PBOX POBox Address is a postal office (PO) box.

2.1.25 AddressLine <AdrLine>Presence: [0..5]


Message Item Types

Page 242

Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text.


minLength: 1

2.1.26 StreetName <StrtNm>Presence: [0..1]Definition: Name of a street or thoroughfare.Data Type: Max70TextFormat: maxLength: 70

minLength: 1

2.1.27 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16TextFormat: maxLength: 16

minLength: 1

2.1.28 PostCode <PstCd>Presence: [0..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting

of mail.Data Type: Max16TextFormat: maxLength: 16

minLength: 1

2.1.29 TownName <TwnNm>Presence: [0..1]Definition: Name of a built-up area, with defined boundaries, and a local government.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

2.1.30 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

2.1.31 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCode


Message Item Types

Page 243

Format: [A-Z]{2,2}Rule(s): Country

The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).

2.1.32 ProprietaryIdentification <PrtryId>Presence: [0..1]Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification

scheme.Type: This message item is composed of the following GenericIdentification3 element(s):





minLength: 1

2.1.34 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

2.1.35 BranchIdentification <BrnchId>Presence: [0..1]Definition: Information identifying a specific branch of a financial institution.

Usage : this component should be used in case the identification information in the financial institution component does not provide identification up to branch level.

Type: This message item is composed of the following BranchData element(s):



2.1.37 Name <Nm> [0..1] Text



Message Item Types

Page 244

2.1.36 Identification <Id>Presence: [0..1]Definition: Unique and unambiguous identification of a branch of a financial institution.Data Type: Max35TextFormat: maxLength: 35

minLength: 1


minLength: 1

2.1.38 PostalAddress <PstlAdr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of the following PostalAddress1 element(s):

















Message Item Types

Page 245

Code Name DefinitionPBOX POBox Address is a postal office (PO) box.

2.1.40 AddressLine <AdrLine>Presence: [0..5]Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in

free format text.Data Type: Max70TextFormat: maxLength: 70

minLength: 1


minLength: 1

2.1.42 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16TextFormat: maxLength: 16

minLength: 1



minLength: 1


minLength: 1

2.1.45 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35Text


Message Item Types

Page 246


2.1.46 Country <Ctry>Presence: [1..1]Definition: Nation with its own government.Data Type: CountryCodeFormat: [A-Z]{2,2}Rule(s): Country


3 Party identification

3.1 Intermediary1Intermediary1 is used in message AdditionalPaymentInformation p.30.

Definition: Organised structure that is set up for a particular purpose, eg, a business, government body, department, charity, or financial institution.

Type: The following Intermediary1 element(s) must be used:



3.1.1 {Or BICOrBEI <BICOrBEI> [1..1] Identifier

3.1.2 Or ProprietaryIdentification <PrtryId> [1..1]


3.1.4 SchemeName <SchmeNm> [0..1] Text


3.1.6 Or} NameAndAddress <NmAndAdr> [1..1]

3.1.7 Name <Nm> [1..1] Text

3.1.8 Address <Adr> [0..1]

3.1.9 {{Or Unstructured <Ustrd> [1..1] Text

3.1.10 Or}} Structured <Strd> [1..1]

3.1.11 BuildingName <BldgNm> [0..1] Text


3.1.13 StreetBuildingIdentification <StrtBldgId> [0..1] Text

3.1.14 Floor <Flr> [0..1] Text


3.1.16 DistrictName <DstrctNm> [0..1] Text

3.1.17 RegionIdentification <RgnId> [0..1] Text

3.1.18 State <Stat> [0..1] Text


Message Item Types

Page 247


3.1.19 CountyIdentification <CtyId> [0..1] Text


3.1.21 PostCodeIdentification <PstCdId> [1..1] Text

3.1.22 PostOfficeBox <POB> [0..1] Text

3.1.23 Account <Acct> [0..1]


3.1.25 Proprietary <Prtry> [1..1]


3.1.27 AccountServicer <AcctSvcr> [1..1]







3.1.34 Name <Nm> [1..1] Text

3.1.35 Address <Adr> [0..1]

3.1.36 {{Or Unstructured <Ustrd> [1..1] Text

3.1.37 Or}} Structured <Strd> [1..1]













3.1.50 Role <Role> [0..1] Text

3.1.0 Identification <Id>Presence: [1..1]


Message Item Types

Page 248

Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet Identification.

Type: This message item is composed of one of the following PartyIdentification1Choice element(s):





3.1.1 BICOrBEI <BICOrBEI>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet

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


3.1.2 ProprietaryIdentification <PrtryId>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification






3.1.3 Identification <Id>Presence: [1..1]Definition: Identification assigned by an institution.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.4 SchemeName <SchmeNm>Presence: [0..1]


Message Item Types

Page 249

Definition: Name of the identification scheme, eg, "UK National Insurance Number".Data Type: Max35TextFormat: maxLength: 35

minLength: 1


minLength: 1

3.1.6 NameAndAddress <NmAndAdr>Presence: [1..1]This message item is part of choice 3.1.0 Identification.Definition: Name by which a party is known and which is usually used to identify that party.Type: This message item is composed of the following NameAndAddress2 element(s):


3.1.7 Name <Nm> [1..1] Text

3.1.8 Address <Adr> [0..1]


minLength: 1

3.1.8 Address <Adr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of one of the following LongPostalAddress1Choice element(s):


3.1.9 {Or Unstructured <Ustrd> [1..1] Text

3.1.10 Or} Structured <Strd> [1..1]

3.1.9 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 3.1.8 Address.


Message Item Types

Page 250

Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in free format text.


minLength: 1

3.1.10 Structured <Strd>Presence: [1..1]This message item is part of choice 3.1.8 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in

a formal structure.Type: This message item is composed of the following StructuredLongPostalAddress1 element(s):














Rule(s): StreetNameAndOrPostOfficeBoxRule If StreetName is not present, then PostOfficeBox is mandatory. If StreetName is present, then PostOfficeBox is optional.

3.1.11 BuildingName <BldgNm>Presence: [0..1]Definition: Name of the building or house.Data Type: Max35TextFormat: maxLength: 35

minLength: 1



Message Item Types

Page 251

minLength: 1

3.1.13 StreetBuildingIdentification <StrtBldgId>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.14 Floor <Flr>Presence: [0..1]Definition: Floor or storey within a building.Data Type: Max16TextFormat: maxLength: 16

minLength: 1


minLength: 1

3.1.16 DistrictName <DstrctNm>Presence: [0..1]Definition: Name of a district, ie, a part of a town or region.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.17 RegionIdentification <RgnId>Presence: [0..1]Definition: Identification of an administrative division of a country, state, or territory.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.18 State <Stat>Presence: [0..1]Definition: Organised political community or area forming a part of a federation.Data Type: Max35TextFormat: maxLength: 35

minLength: 1


Message Item Types

Page 252

3.1.19 CountyIdentification <CtyId>Presence: [0..1]Definition: Identifier of a county.Data Type: Max35TextFormat: maxLength: 35

minLength: 1



3.1.21 PostCodeIdentification <PstCdId>Presence: [1..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting


minLength: 1

3.1.22 PostOfficeBox <POB>Presence: [0..1]Definition: Numbered box in a post office, assigned to a person or organisation, where letters are kept until called for.Data Type: Max16TextFormat: maxLength: 16

minLength: 1

3.1.23 Account <Acct>Presence: [0..1]Definition: Business relationship between two entities; one entity is the account owner, the other entity is the account

servicer.Type: This message item is composed of the following Account1 element(s):



3.1.27 AccountServicer <AcctSvcr> [1..1]

3.1.24 Identification <Id>Presence: [0..1]


Message Item Types

Page 253

Definition: Unique and unambiguous identification for the account between the account owner and the account servicer.Type: This message item is composed of the following AccountIdentification1 element(s):


3.1.25 Proprietary <Prtry> [1..1]

3.1.25 Proprietary <Prtry>Presence: [1..1]Definition: Unique identifier for an account. It is assigned by the account servicer using a proprietary identification

scheme.Type: This message item is composed of the following SimpleIdentificationInformation element(s):




minLength: 1

3.1.27 AccountServicer <AcctSvcr>Presence: [1..1]Definition: Institution servicing an account and assigning the account identifier to the account owner.Type: This message item is composed of one of the following PartyIdentification1Choice element(s):





3.1.28 BICOrBEI <BICOrBEI>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution, eg, Dun & Bradstreet

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


Message Item Types

Page 254


3.1.29 ProprietaryIdentification <PrtryId>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Unique and unambiguous identifier, as assigned to a financial institution using a proprietary identification






3.1.30 Identification <Id>Presence: [1..1]Definition: Identification assigned by an institution.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.31 SchemeName <SchmeNm>Presence: [0..1]Definition: Name of the identification scheme, eg, "UK National Insurance Number".Data Type: Max35TextFormat: maxLength: 35

minLength: 1


minLength: 1

3.1.33 NameAndAddress <NmAndAdr>Presence: [1..1]This message item is part of choice 3.1.27 AccountServicer.Definition: Name by which a party is known and which is usually used to identify that party.Type: This message item is composed of the following NameAndAddress2 element(s):


Message Item Types

Page 255


3.1.34 Name <Nm> [1..1] Text

3.1.35 Address <Adr> [0..1]


minLength: 1

3.1.35 Address <Adr>Presence: [0..1]Definition: Information that locates and identifies a specific address, as defined by postal services.Type: This message item is composed of one of the following LongPostalAddress1Choice element(s):


3.1.36 {Or Unstructured <Ustrd> [1..1] Text

3.1.37 Or} Structured <Strd> [1..1]

3.1.36 Unstructured <Ustrd>Presence: [1..1]This message item is part of choice 3.1.35 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in


minLength: 1

3.1.37 Structured <Strd>Presence: [1..1]This message item is part of choice 3.1.35 Address.Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in

a formal structure.Type: This message item is composed of the following StructuredLongPostalAddress1 element(s):







Message Item Types

Page 256










Rule(s): StreetNameAndOrPostOfficeBoxRule If StreetName is not present, then PostOfficeBox is mandatory. If StreetName is present, then PostOfficeBox is optional.

3.1.38 BuildingName <BldgNm>Presence: [0..1]Definition: Name of the building or house.Data Type: Max35TextFormat: maxLength: 35

minLength: 1


minLength: 1

3.1.40 StreetBuildingIdentification <StrtBldgId>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.41 Floor <Flr>Presence: [0..1]Definition: Floor or storey within a building.Data Type: Max16TextFormat: maxLength: 16

minLength: 1


Message Item Types

Page 257


minLength: 1

3.1.43 DistrictName <DstrctNm>Presence: [0..1]Definition: Name of a district, ie, a part of a town or region.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.44 RegionIdentification <RgnId>Presence: [0..1]Definition: Identification of an administrative division of a country, state, or territory.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.45 State <Stat>Presence: [0..1]Definition: Organised political community or area forming a part of a federation.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.1.46 CountyIdentification <CtyId>Presence: [0..1]Definition: Identifier of a county.Data Type: Max35TextFormat: maxLength: 35

minLength: 1




Message Item Types

Page 258

3.1.48 PostCodeIdentification <PstCdId>Presence: [1..1]Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting


minLength: 1

3.1.49 PostOfficeBox <POB>Presence: [0..1]Definition: Numbered box in a post office, assigned to a person or organisation, where letters are kept until called for.Data Type: Max16TextFormat: maxLength: 16

minLength: 1

3.1.50 Role <Role>Presence: [0..1]Definition: Set of functions performed by an intermediary in a given situation.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2 PartyIdentification1PartyIdentification1 is used in message AdditionalPaymentInformation p.30, p.30, p.30, p.30, message RequestToModifyPayment p.156, p.156, p.156, p.156.

Definition: Entity involved in an activity.Type: The following PartyIdentification1 element(s) must be used:


3.2.0 Name <Nm> [0..1] Text











3.2.11 {Or OrganisationIdentification <OrgId> [1..1]


Message Item Types

Page 259


3.2.12 BEI <BEI> [0..1] Identifier

3.2.13 EANGLN <EANGLN> [0..1] Identifier

3.2.14 CHIPSUniversalIdentification <USCHU> [0..1] Identifier

3.2.15 DUNS <DUNS> [0..1] Identifier

3.2.16 BankPartyIdentification <BkPtyId> [0..1] Text

3.2.17 TaxIdentificationNumber <TaxIdNb> [0..1] Text




3.2.21 Or} PrivateIdentification <PrvtId> [1..2]

3.2.22 {{Or DriversLicenseNumber <DrvrsLicNb> [1..1] Text

3.2.23 Or SocialSecurityNumber <SclSctyNb> [1..1] Text

3.2.24 Or AlienRegistrationNumber <AlnRegnNb> [1..1] Text

3.2.25 Or PassportNumber <PsptNb> [1..1] Text

3.2.26 Or TaxIdentificationNumber <TaxIdNb> [1..1] Text

3.2.27 Or IdentityCardNumber <IdntyCardNb> [1..1] Text

3.2.28 Or EmployerIdentificationNumber <MplyrIdNb> [1..1] Text

3.2.29 Or}} OtherIdentification <OthrId> [1..1]


3.2.31 IdentificationType <IdTp> [1..1] Text



minLength: 1

3.2.1 PostalAddress <PstlAdr>Presence: [0..1]Definition: Postal address of a party.Type: This message item is composed of the following PostalAddress1 element(s):





Message Item Types

Page 260














PBOX POBox Address is a postal office (PO) box.

3.2.3 AddressLine <AdrLine>Presence: [0..5]Definition: Information that locates and identifies a specific address, as defined by postal services, that is presented in


minLength: 1


minLength: 1

3.2.5 BuildingNumber <BldgNb>Presence: [0..1]Definition: Number that identifies the position of a building on a street.Data Type: Max16Text


Message Item Types

Page 261




minLength: 1


minLength: 1

3.2.8 CountrySubDivision <CtrySubDvsn>Presence: [0..1]Definition: Identifies a subdivision of a country eg, state, region, county.Data Type: Max35TextFormat: maxLength: 35

minLength: 1



3.2.10 Identification <Id>Presence: [0..1]Definition: Unique and unambiguous identification of a party.Type: This message item is composed of one of the following Party1Choice element(s):


3.2.11 {Or OrganisationIdentification <OrgId> [1..1]

3.2.21 Or} PrivateIdentification <PrvtId> [1..2]


Message Item Types

Page 262

3.2.11 OrganisationIdentification <OrgId>Presence: [1..1]This message item is part of choice 3.2.10 Identification.Definition: Unique and unambiguous way of identifying an organisation.Type: This message item is composed of the following NonFinancialInstitutionIdentification1 element(s):


3.2.12 BEI <BEI> [0..1] Identifier

3.2.13 EANGLN <EANGLN> [0..1] Identifier

3.2.14 CHIPSUniversalIdentification <USCHU> [0..1] Identifier

3.2.15 DUNS <DUNS> [0..1] Identifier

3.2.16 BankPartyIdentification <BkPtyId> [0..1] Text

3.2.17 TaxIdentificationNumber <TaxIdNb> [0..1] Text


3.2.12 BEI <BEI>Presence: [0..1]Definition: Business Entity Identifier. Code allocated to non-financial institutions by the ISO 9362 Registration

Authority. The Business Entity Identifier (BEI) has the same format as the BIC code (8 up to 11 characters) as stipulated in the standard ISO 9362 Banking (Banking Telecommunication Messages, Bank Identifier Codes, BIC).

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

Only Business Entity Identifiers registered with the ISO 9362 Registration Authority and consisting of 8 or 11 contiguous characters comprising the first three or all four of the following components: BANK CODE, COUNTRY CODE, LOCATION CODE, BRANCH CODE, are valid BEIs.

3.2.13 EANGLN <EANGLN>Presence: [0..1]Definition: Global Location Number. A non-significant reference number used to identify legal entities, functional

entities or physical entities according to the European Association for Numbering (EAN) numbering scheme rules. The number is used to retrieve detailed information linked to it.

Data Type: EANGLNIdentifierFormat: [0-9]{13,13}

3.2.14 CHIPSUniversalIdentification <USCHU>Presence: [0..1]Definition: (United States) Clearing House Interbank Payments System (CHIPS) Universal Identification (UID) -

identifies entities that own accounts at CHIPS participating financial institutions, through which CHIPS payments are effected. The CHIPS UID is assigned by the New York Clearing House.


Message Item Types

Page 263

Data Type: CHIPSUniversalIdentifierFormat: CH[0-9]{6,6}

3.2.15 DUNS <DUNS>Presence: [0..1]Definition: Data Universal Numbering System. A unique identification number provided by Dun & Bradstreet to identify

an organization.Data Type: DunsIdentifierFormat: [0-9]{9,9}

3.2.16 BankPartyIdentification <BkPtyId>Presence: [0..1]Definition: Unique and unambiguous assignment made by a specific bank to identify a relationship as defined between

the bank and its client.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.17 TaxIdentificationNumber <TaxIdNb>Presence: [0..1]Definition: Number assigned by a tax authority to an entity.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.18 ProprietaryIdentification <PrtryId>Presence: [0..1]Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution.Type: This message item is composed of the following GenericIdentification3 element(s):





minLength: 1

3.2.20 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identification.


Message Item Types

Page 264


minLength: 1

3.2.21 PrivateIdentification <PrvtId>Presence: [1..2]This message item is part of choice 3.2.10 Identification.Definition: Unique and unambiguous identification of a person, eg, passport.Type: This message item is composed of the following PersonIdentification2 element(s):


3.2.22 {Or DriversLicenseNumber <DrvrsLicNb> [1..1] Text

3.2.23 Or SocialSecurityNumber <SclSctyNb> [1..1] Text

3.2.24 Or AlienRegistrationNumber <AlnRegnNb> [1..1] Text

3.2.25 Or PassportNumber <PsptNb> [1..1] Text

3.2.26 Or TaxIdentificationNumber <TaxIdNb> [1..1] Text

3.2.27 Or IdentityCardNumber <IdntyCardNb> [1..1] Text

3.2.28 Or EmployerIdentificationNumber <MplyrIdNb> [1..1] Text

3.2.29 Or} OtherIdentification <OthrId> [1..1]


3.2.22 DriversLicenseNumber <DrvrsLicNb>Synonym(s): :95S::ALTE//DRLC (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a license authority to a driver's license.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.23 SocialSecurityNumber <SclSctyNb>Synonym(s): :95S::ALTE//SSNX (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a social security agency.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.24 AlienRegistrationNumber <AlnRegnNb>Synonym(s): :95S::ALTE//ARNU (ISO 15022)Presence: [1..1]


Message Item Types

Page 265

This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a government agency to identify foreign nationals.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.25 PassportNumber <PsptNb>Synonym(s): :95S::ALTE//CCPT (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a passport authority to a passport.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.26 TaxIdentificationNumber <TaxIdNb>Synonym(s): :95S::ALTE//TXID (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a tax authority to an entity.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.27 IdentityCardNumber <IdntyCardNb>Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned by a national authority to an identity card.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.28 EmployerIdentificationNumber <MplyrIdNb>Synonym(s): :95S::ALTE//EINX (ISO 15022)Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Number assigned to an employer by a registration authority.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.29 OtherIdentification <OthrId>Presence: [1..1]This message item is part of choice 3.2.21 PrivateIdentification.Definition: Identifier issued to a person for which no specific identifier has been defined.


Message Item Types

Page 266

Type: This message item is composed of the following GenericIdentification4 element(s):



3.2.31 IdentificationType <IdTp> [1..1] Text

3.2.30 Identification <Id>Presence: [1..1]Definition: Identifier issued to a person for which no specific identifier has been defined.Data Type: Max35TextFormat: maxLength: 35

minLength: 1

3.2.31 IdentificationType <IdTp>Presence: [1..1]Definition: Specifies the nature of the identifier.

Usage: IdentificationType is used to specify what kind of identifier is used. It should be used in case the identifier is different from the identifiers listed in the pre-defined identifier list.


minLength: 1

3.2.32 Issuer <Issr>Presence: [0..1]Definition: Entity that assigns the identifier.Data Type: Max35TextFormat: maxLength: 35

minLength: 1


Message Item Types

Page 267

IndexesIndex of Message ItemsAAccount: <Acct>

248

AccountServicer: <AcctSvcr>248

Address: <Adr>247, 248

AddressLine: <AdrLine>236, 237, 259

AddressType: <AdrTp>236, 237, 259

AlienRegistrationNumber: <AlnRegnNb>260

Amount: <Amt>Message AdditionalPaymentInformation 30, 30

AmountToDebit: <AmtToDbt>Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141

AnyInformation: <AnyInf>Message UnableToApply 198

Assignee: <Assgne>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

AssigneeInstructionIdentification: <AssgneInstrId>Message AdditionalPaymentInformation 29


Indexes

Page 268

Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

Assigner: <Assgnr>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

AssignerInstructionIdentification: <AssgnrInstrId>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

Assignment: <Assgnmt>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

AssignmentCancellationConfirmation: <AssgnmtCxlConf>Message ResolutionOfInvestigation 186

AustralianExtensiveBranchNetworkIdentification: <AUBSBx>236

AustralianSmallNetworkIdentification: <AUBSBs>


Indexes

Page 269

236

AustrianBankleitzahlIdentification: <ATBLZ>236

BBankOperationCode: <BkOprCd>

Message RequestToModifyPayment 155

BankPartyIdentification: <BkPtyId>260

BBAN: <BBAN>233

BEI: <BEI>260

BeneficiaryInstitutionAccount: <BnfcryInstnAcct>Message RequestToModifyPayment 156

BIC: <BIC>235

BICOrBEI: <BICOrBEI>247, 248

BranchIdentification: <BrnchId>236

BuildingName: <BldgNm>247, 248

BuildingNumber: <BldgNb>236, 237, 259

CCanadianPaymentsAssociationRoutingNumberIdentification: <CACPA>

236

CancellationReason: <CxlRsn>Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141

Case: <Case>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68


Indexes

Page 270

Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message UnableToApply 197

CaseStatus: <CaseSts>Message CaseStatusReport 59

CHIPSParticipantIdentification: <USCH>236

CHIPSUniversalIdentification: <USCHU>235, 260

ClearingSystemMemberIdentification: <ClrSysMmbId>235

Code: <Cd>Message RequestToModifyPayment 156, 156, 156

Confirmation: <Conf>Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186

CorrectionTransaction: <CrrctnTx>Message ResolutionOfInvestigation 187

Country: <Ctry>236, 237, 248, 248, 259

CountrySubDivision: <CtrySubDvsn>236, 237, 259

CountyIdentification: <CtyId>248, 248

CreationDateTime: <CreDtTm>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133


Indexes

Page 271

Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

Creator: <Cretr>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197

CreditNoteAmount: <CdtNoteAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

Creditor: <Cdtr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

CreditorAccount: <CdtrAcct>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

CreditorReference: <CdtrRef>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

Currency: <Ccy>233

CurrencyAmount: <CcyAmt>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

CurrencyOfTransfer: <CcyOfTrf>Message AdditionalPaymentInformation 30


Indexes

Page 272

DDateTime: <DtTm>

Message CaseStatusReport 59

DebitAuthorisation: <DbtAuthstn>Message DebitAuthorisationResponse 105

Debtor: <Dbtr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

DebtorAccount: <DbtrAcct>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

Detail: <Dtl>Message DebitAuthorisationRequest 94

DetailsOfCharges: <DtlsOfChrgs>Message RequestToModifyPayment 156

DiscountAppliedAmount: <DscntApldAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

DistrictName: <DstrctNm>247, 248

DocumentReferenceNumber: <DocRefNb>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

DomesticAccount: <DmstAcct>233

DriversLicenseNumber: <DrvrsLicNb>260

DuePayableAmount: <DuePyblAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

DUNS: <DUNS>260

DuplicateOf: <DplctOf>Message ResolutionOfInvestigation 186

EEANGLN: <EANGLN>


Indexes

Page 273

260

EmployerIdentificationNumber: <MplyrIdNb>260

EquivalentAmount: <EqvtAmt>Message AdditionalPaymentInformation 30

FFedwireRoutingNumberIdentification: <USFW>

236

FinancialInstitutionIdentification: <FinInstnId>235

FirstAgent: <FrstAgt>Message AdditionalPaymentInformation 30

FirstSettlementAgent: <FrstSttlmAgt>Message AdditionalPaymentInformation 30

Floor: <Flr>247, 248

From: <Fr>Message CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115

GGermanBankleitzahlIdentification: <DEBLZ>

236

HHeader: <Hdr>

Message CaseStatusReport 58Message NotificationOfCaseAssignment 115

HongKongBankCode: <HKNCC>236

IIBAN: <IBAN>

233

Identification: <Id>233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260


Indexes

Page 274

Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 197

IdentificationType: <IdTp>260

IdentityCardNumber: <IdntyCardNb>260

IncorrectInformation: <IncrrctInf>Message UnableToApply 198

Information: <Inf>Message AdditionalPaymentInformation 29

InstructedAmount: <InstdAmt>Message AdditionalPaymentInformation 30

InstructionCode: <InstrCd>Message RequestToModifyPayment 155

InstructionForFinalAgent: <InstrForFnlAgt>Message RequestToModifyPayment 156

InterbankSettledAmount: <IntrBkSttldAmt>Message RequestToModifyPayment 156

Intermediary: <Intrmy>Message AdditionalPaymentInformation 30

IntermediarySettlementAgent: <IntrmySttlmAgt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

InvestigationStatus: <InvstgtnSts>Message CaseStatusReport 59

Invoicee: <Invcee>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156


Indexes

Page 275

Invoicer: <Invcr>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

IrishNSCIdentification: <IENSC>236

Issuer: <Issr>236, 247, 248, 260, 260

ItalianDomesticIdentificationCode: <ITNCC>236

JJustification: <Justfn>

Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestToCancelPayment 141Message UnableToApply 198

LLastSettlementAgent: <LastSttlmAgt>

Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

MMissingCover: <MssngCover>

Message ClaimNonReceipt 75

MissingCoverIndication: <MssngCoverIndctn>Message ClaimNonReceipt 75

MissingInformation: <MssngInf>Message UnableToApply 198

MissingOrIncorrectInformation: <MssngOrIncrrctInf>Message UnableToApply 198

Modification: <Mod>Message RequestToModifyPayment 155

NName: <Nm>

233, 236, 236, 247, 248, 259

NameAndAddress: <NmAndAdr>


Indexes

Page 276

247, 248

NewAssignment: <NewAssgnmt>Message CaseStatusReport 59

NewZealandNCCIdentification: <NZNCC>235

NostroVostroAccount: <NstrVstrAcct>Message AdditionalPaymentInformation 30

Notification: <Ntfctn>Message NotificationOfCaseAssignment 115

OOrganisationIdentification: <OrgId>

259

OtherIdentification: <OthrId>260

PPassportNumber: <PsptNb>

260

PaymentScheme: <PmtSchme>Message RequestToModifyPayment 156

PortugueseNCCIdentification: <PTNCC>236

PostalAddress: <PstlAdr>236, 237, 259

PostCode: <PstCd>236, 237, 259

PostCodeIdentification: <PstCdId>248, 248

PostOfficeBox: <POB>248, 248

PrivateIdentification: <PrvtId>260

Proprietary: <Prtry>248Message RequestToModifyPayment 156, 156


Indexes

Page 277

ProprietaryIdentification: <PrtryId>236, 247, 248, 260

ProprietaryInformation: <PrtryInf>Message RequestToModifyPayment 156

Purpose: <Purp>Message RequestToModifyPayment 156

RReason: <Rsn>

Message CaseStatusReport 59Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186

ReasonCode: <RsnCd>Message ResolutionOfInvestigation 186

ReferredDocumentAmount: <RfrdDocAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

ReferredDocumentRelatedDate: <RfrdDocRltdDt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

ReferredDocumentType: <RfrdDocTp>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

RegionIdentification: <RgnId>247, 248

RejectedCancellation: <RjctdCxl>Message ResolutionOfInvestigation 186

RejectedModification: <RjctdMod>Message ResolutionOfInvestigation 186

RejectionReason: <RjctnRsn>Message RejectCaseAssignment 127

RelatedReference: <RltdRef>Message RequestToModifyPayment 155

RemittanceChoice: <RmtChc>Message AdditionalPaymentInformation 29

RemittanceInformation: <RmtInf>Message RequestToModifyPayment 156


Indexes

Page 278

RemittedAmount: <RmtdAmt>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

ReopenCaseIndication: <ReopCaseIndctn>Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197

RequestedExecutionDate: <ReqdExctnDt>Message RequestToModifyPayment 155

RequestHeader: <ReqHdr>Message CaseStatusReportRequest 67

ResolvedCase: <RslvdCase>Message ResolutionOfInvestigation 186

Role: <Role>248

RussianCentralBankIdentificationCode: <RUCB>236

SSchemeName: <SchmeNm>

247, 248

SenderToReceiverInformation: <SndrToRcvrInf>Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

SocialSecurityNumber: <SclSctyNb>260

SouthAfricanNCCIdentification: <ZANCC>236

SpanishDomesticInterbankingIdentification: <ESNCC>


Indexes

Page 279

236

State: <Stat>247, 248

Status: <Sts>Message CaseStatusReport 59Message ResolutionOfInvestigation 186

StreetBuildingIdentification: <StrtBldgId>247, 248

StreetName: <StrtNm>236, 237, 247, 248, 259

Structured: <Strd>247, 248Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

SwissBCIdentification: <CHBC>236

SwissSICIdentification: <CHSIC>236

TTaxAmount: <TaxAmt>


TaxIdentificationNumber: <TaxIdNb>260, 260

To: <To>Message CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115

TownName: <TwnNm>236, 237, 247, 248, 259

Type: <Tp>233

UUKDomesticSortCode: <GBSC>

236


Indexes

Page 280

Underlying: <Undrlyg>Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message UnableToApply 198

Unstructured: <Ustrd>247, 248Message AdditionalPaymentInformation 29Message RequestToModifyPayment 156

UPIC: <UPIC>233

VValueDate: <ValDt>

Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 187Message UnableToApply 198

ValueDateToDebit: <ValDtToDbt>Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141

Index of XML tagsA<Acct>: Account

248

<AcctSvcr>: AccountServicer248

<Adr>: Address247, 248

<AdrLine>: AddressLine236, 237, 259

<AdrTp>: AddressType236, 237, 259


Indexes

Page 281

<AlnRegnNb>: AlienRegistrationNumber260

<Amt>: AmountMessage AdditionalPaymentInformation 30, 30

<AmtToDbt>: AmountToDebitMessage DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141

<AnyInf>: AnyInformationMessage UnableToApply 198

<Assgne>: AssigneeMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

<AssgneInstrId>: AssigneeInstructionIdentificationMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

<Assgnmt>: AssignmentMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197


Indexes

Page 282

<AssgnmtCxlConf>: AssignmentCancellationConfirmationMessage ResolutionOfInvestigation 186

<Assgnr>: AssignerMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

<AssgnrInstrId>: AssignerInstructionIdentificationMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

<ATBLZ>: AustrianBankleitzahlIdentification236

<AUBSBs>: AustralianSmallNetworkIdentification236

<AUBSBx>: AustralianExtensiveBranchNetworkIdentification236

B<BBAN>: BBAN

233

<BEI>: BEI260

<BIC>: BIC235

<BICOrBEI>: BICOrBEI247, 248

<BkOprCd>: BankOperationCodeMessage RequestToModifyPayment 155


Indexes

Page 283

<BkPtyId>: BankPartyIdentification260

<BldgNb>: BuildingNumber236, 237, 259

<BldgNm>: BuildingName247, 248

<BnfcryInstnAcct>: BeneficiaryInstitutionAccountMessage RequestToModifyPayment 156

<BrnchId>: BranchIdentification236

C<CACPA>: CanadianPaymentsAssociationRoutingNumberIdentification

236

<Case>: CaseMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message UnableToApply 197

<CaseSts>: CaseStatusMessage CaseStatusReport 59

<Ccy>: Currency233

<CcyAmt>: CurrencyAmountMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

<CcyOfTrf>: CurrencyOfTransfer


Indexes

Page 284

Message AdditionalPaymentInformation 30

<Cd>: CodeMessage RequestToModifyPayment 156, 156, 156

<CdtNoteAmt>: CreditNoteAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<Cdtr>: CreditorMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<CdtrAcct>: CreditorAccountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<CdtrRef>: CreditorReferenceMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<CHBC>: SwissBCIdentification236

<CHSIC>: SwissSICIdentification236

<ClrSysMmbId>: ClearingSystemMemberIdentification235

<Conf>: ConfirmationMessage DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186

<CreDtTm>: CreationDateTimeMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

<Cretr>: CreatorMessage AdditionalPaymentInformation 29


Indexes

Page 285

Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197

<CrrctnTx>: CorrectionTransactionMessage ResolutionOfInvestigation 187

<Ctry>: Country236, 237, 248, 248, 259

<CtrySubDvsn>: CountrySubDivision236, 237, 259

<CtyId>: CountyIdentification248, 248

<CxlRsn>: CancellationReasonMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141

D<DbtAuthstn>: DebitAuthorisation

Message DebitAuthorisationResponse 105

<Dbtr>: DebtorMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<DbtrAcct>: DebtorAccountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<DEBLZ>: GermanBankleitzahlIdentification236

<DmstAcct>: DomesticAccount233

<DocRefNb>: DocumentReferenceNumberMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156


Indexes

Page 286

<DplctOf>: DuplicateOfMessage ResolutionOfInvestigation 186

<DrvrsLicNb>: DriversLicenseNumber260

<DscntApldAmt>: DiscountAppliedAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<DstrctNm>: DistrictName247, 248

<Dtl>: DetailMessage DebitAuthorisationRequest 94

<DtlsOfChrgs>: DetailsOfChargesMessage RequestToModifyPayment 156

<DtTm>: DateTimeMessage CaseStatusReport 59

<DuePyblAmt>: DuePayableAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<DUNS>: DUNS260

E<EANGLN>: EANGLN

260

<EqvtAmt>: EquivalentAmountMessage AdditionalPaymentInformation 30

<ESNCC>: SpanishDomesticInterbankingIdentification236

F<FinInstnId>: FinancialInstitutionIdentification

235

<Flr>: Floor247, 248

<Fr>: FromMessage CaseStatusReport 59


Indexes

Page 287

Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115

<FrstAgt>: FirstAgentMessage AdditionalPaymentInformation 30

<FrstSttlmAgt>: FirstSettlementAgentMessage AdditionalPaymentInformation 30

G<GBSC>: UKDomesticSortCode

236

H<Hdr>: Header

Message CaseStatusReport 58Message NotificationOfCaseAssignment 115

<HKNCC>: HongKongBankCode236

I<IBAN>: IBAN

233

<Id>: Identification233, 233, 236, 236, 247, 247, 248, 248, 248, 259, 260, 260Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 197

<IdntyCardNb>: IdentityCardNumber260

<IdTp>: IdentificationType260


Indexes

Page 288

<IENSC>: IrishNSCIdentification236

<IncrrctInf>: IncorrectInformationMessage UnableToApply 198

<Inf>: InformationMessage AdditionalPaymentInformation 29

<InstdAmt>: InstructedAmountMessage AdditionalPaymentInformation 30

<InstrCd>: InstructionCodeMessage RequestToModifyPayment 155

<InstrForFnlAgt>: InstructionForFinalAgentMessage RequestToModifyPayment 156

<IntrBkSttldAmt>: InterbankSettledAmountMessage RequestToModifyPayment 156

<Intrmy>: IntermediaryMessage AdditionalPaymentInformation 30

<IntrmySttlmAgt>: IntermediarySettlementAgentMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<Invcee>: InvoiceeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<Invcr>: InvoicerMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<InvstgtnSts>: InvestigationStatusMessage CaseStatusReport 59

<Issr>: Issuer236, 247, 248, 260, 260

<ITNCC>: ItalianDomesticIdentificationCode236

J<Justfn>: Justification

Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestToCancelPayment 141Message UnableToApply 198


Indexes

Page 289

L<LastSttlmAgt>: LastSettlementAgent


M<Mod>: Modification


<MplyrIdNb>: EmployerIdentificationNumber260

<MssngCover>: MissingCoverMessage ClaimNonReceipt 75

<MssngCoverIndctn>: MissingCoverIndicationMessage ClaimNonReceipt 75

<MssngInf>: MissingInformationMessage UnableToApply 198

<MssngOrIncrrctInf>: MissingOrIncorrectInformationMessage UnableToApply 198

N<NewAssgnmt>: NewAssignment

Message CaseStatusReport 59

<Nm>: Name233, 236, 236, 247, 248, 259

<NmAndAdr>: NameAndAddress247, 248

<NstrVstrAcct>: NostroVostroAccountMessage AdditionalPaymentInformation 30

<Ntfctn>: NotificationMessage NotificationOfCaseAssignment 115

<NZNCC>: NewZealandNCCIdentification235

O<OrgId>: OrganisationIdentification

259


Indexes

Page 290

<OthrId>: OtherIdentification260

P<PmtSchme>: PaymentScheme


<POB>: PostOfficeBox248, 248

<Prtry>: Proprietary248Message RequestToModifyPayment 156, 156

<PrtryId>: ProprietaryIdentification236, 247, 248, 260

<PrtryInf>: ProprietaryInformationMessage RequestToModifyPayment 156

<PrvtId>: PrivateIdentification260

<PsptNb>: PassportNumber260

<PstCd>: PostCode236, 237, 259

<PstCdId>: PostCodeIdentification248, 248

<PstlAdr>: PostalAddress236, 237, 259

<PTNCC>: PortugueseNCCIdentification236

<Purp>: PurposeMessage RequestToModifyPayment 156

R<ReopCaseIndctn>: ReopenCaseIndication

Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74


Indexes

Page 291

Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197

<ReqdExctnDt>: RequestedExecutionDateMessage RequestToModifyPayment 155

<ReqHdr>: RequestHeaderMessage CaseStatusReportRequest 67

<RfrdDocAmt>: ReferredDocumentAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<RfrdDocRltdDt>: ReferredDocumentRelatedDateMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<RfrdDocTp>: ReferredDocumentTypeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<RgnId>: RegionIdentification247, 248

<RjctdCxl>: RejectedCancellationMessage ResolutionOfInvestigation 186

<RjctdMod>: RejectedModificationMessage ResolutionOfInvestigation 186

<RjctnRsn>: RejectionReasonMessage RejectCaseAssignment 127

<RltdRef>: RelatedReferenceMessage RequestToModifyPayment 155

<RmtChc>: RemittanceChoiceMessage AdditionalPaymentInformation 29

<RmtdAmt>: RemittedAmountMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<RmtInf>: RemittanceInformationMessage RequestToModifyPayment 156


Indexes

Page 292

<Role>: Role248

<RslvdCase>: ResolvedCaseMessage ResolutionOfInvestigation 186

<Rsn>: ReasonMessage CaseStatusReport 59Message DebitAuthorisationResponse 105Message ResolutionOfInvestigation 186

<RsnCd>: ReasonCodeMessage ResolutionOfInvestigation 186

<RUCB>: RussianCentralBankIdentificationCode236

S<SchmeNm>: SchemeName

247, 248

<SclSctyNb>: SocialSecurityNumber260

<SndrToRcvrInf>: SenderToReceiverInformationMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<Stat>: State247, 248

<Strd>: Structured247, 248Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

<StrtBldgId>: StreetBuildingIdentification247, 248

<StrtNm>: StreetName236, 237, 247, 248, 259

<Sts>: StatusMessage CaseStatusReport 59Message ResolutionOfInvestigation 186

T<TaxAmt>: TaxAmount


Indexes

Page 293


<TaxIdNb>: TaxIdentificationNumber260, 260

<To>: ToMessage CaseStatusReport 59Message CaseStatusReportRequest 68Message NotificationOfCaseAssignment 115

<Tp>: Type233

<TwnNm>: TownName236, 237, 247, 248, 259

U<Undrlyg>: Underlying

Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message UnableToApply 198

<UPIC>: UPIC233

<USCH>: CHIPSParticipantIdentification236

<USCHU>: CHIPSUniversalIdentification235, 260

<USFW>: FedwireRoutingNumberIdentification236

<Ustrd>: Unstructured247, 248Message AdditionalPaymentInformation 29Message RequestToModifyPayment 156

V<ValDt>: ValueDate

Message AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141


Indexes

Page 294

Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 187Message UnableToApply 198

<ValDtToDbt>: ValueDateToDebitMessage DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141

Z<ZANCC>: SouthAfricanNCCIdentification

236

Index of Message Item TypesAAccount1

248

AccountIdentification1248

AccountIdentification1Choice233

AddressType2Code236, 237, 259

AmountType1ChoiceMessage AdditionalPaymentInformation 30

AnyBICIdentifier225, 247, 248Message AdditionalPaymentInformation 29, 29, 29Message CancelCaseAssignment 50, 50, 50Message CaseStatusReport 59, 59, 59, 59, 59Message CaseStatusReportRequest 68, 68, 68Message ClaimNonReceipt 74, 74, 74Message DebitAuthorisationRequest 94, 94, 94Message DebitAuthorisationResponse 104, 104, 105Message NotificationOfCaseAssignment 115, 115, 115, 115, 115Message RejectCaseAssignment 127, 127, 127Message RequestForDuplicateInstruction 133, 133, 134Message RequestToCancelPayment 140, 140, 140Message RequestToModifyPayment 155, 155, 155Message ResolutionOfInvestigation 186, 186, 186, 186Message UnableToApply 197, 197, 197

AustrianBankleitzahlIdentifier


Indexes

Page 295

225, 236

BBBANIdentifier

225, 233

BEIIdentifier225, 260

BICIdentifier226, 235

BranchAndFinancialInstitutionIdentification235Message AdditionalPaymentInformation 30, 30, 30, 30Message RequestToModifyPayment 156, 156

BranchData236

CCanadianPaymentsARNIdentifier

226, 236

CancellationReason1CodeMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141

CaseMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186Message UnableToApply 197

CaseAssignmentMessage AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message ClaimNonReceipt 74


Indexes

Page 296

Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186Message UnableToApply 197

CaseAssignmentRejection1CodeMessage RejectCaseAssignment 127

CaseAssignmentRejectionJustificationMessage RejectCaseAssignment 127

CaseForwardingNotificationMessage NotificationOfCaseAssignment 115

CaseForwardingNotification1CodeMessage NotificationOfCaseAssignment 115

CaseStatusMessage CaseStatusReport 59

CaseStatus1CodeMessage CaseStatusReport 59

CashAccount3232Message AdditionalPaymentInformation 30, 30, 30Message RequestToModifyPayment 156, 156, 156

CashAccountType3Code233

CashClearingSystem2CodeMessage RequestToModifyPayment 156

ChargeBearer1CodeMessage RequestToModifyPayment 156

CHIPSParticipantIdentifier226, 236

CHIPSUniversalIdentifier226, 235, 260

ClearingSystemMemberIdentificationChoice235

CountryCode


Indexes

Page 297

226, 236, 237, 248, 248, 259

CurrencyAndAmount224Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141, 141Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 187Message UnableToApply 198

CurrencyCode227, 233Message AdditionalPaymentInformation 29, 30, 30, 30, 30, 30, 30, 30, 30Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141, 141Message RequestToModifyPayment 155, 156, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 187Message UnableToApply 198

DDebitAuthorisationConfirmation

Message DebitAuthorisationResponse 105

DebitAuthorisationDetailsMessage DebitAuthorisationRequest 94Message RequestToCancelPayment 141

DocumentType1CodeMessage AdditionalPaymentInformation 30Message RequestToModifyPayment 156

DunsIdentifier227, 260

EEANGLNIdentifier

227, 260

EquivalentAmountMessage AdditionalPaymentInformation 30

ExtensiveBranchNetworkIdentifier227, 236


Indexes

Page 298

FFedwireRoutingNumberIdentifier

227, 236

FinancialInstitutionIdentification1235

GGenericIdentification1

247, 248

GenericIdentification3236, 260

GenericIdentification4260

GermanBankleitzahlIdentifier228, 236

HHongKongBankIdentifier

228, 236

IIBANIdentifier

228, 233

ImpliedCurrencyAndAmount224

Instruction1CodeMessage RequestToModifyPayment 155

Instruction3CodeMessage RequestToModifyPayment 156

InstructionForFinalAgentMessage RequestToModifyPayment 156

Intermediary1247Message AdditionalPaymentInformation 30

InvestigationExecutionConfirmation1CodeMessage CaseStatusReport 59Message ResolutionOfInvestigation 186


Indexes

Page 299

InvestigationStatusChoiceMessage ResolutionOfInvestigation 186

IrishNSCIdentifier228, 236

ISODate224Message AdditionalPaymentInformation 30Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105Message RequestToCancelPayment 141Message RequestToModifyPayment 155, 155, 156

ISODateTime225Message AdditionalPaymentInformation 29, 29Message CancelCaseAssignment 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74, 75Message DebitAuthorisationRequest 94, 94Message DebitAuthorisationResponse 104Message NotificationOfCaseAssignment 115, 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 133Message RequestToCancelPayment 140, 141Message RequestToModifyPayment 155, 155Message ResolutionOfInvestigation 186, 187Message UnableToApply 197, 198

ItalianDomesticIdentifier228, 236

LLanguageCode

228

LongPostalAddress1Choice247, 248

MMax10Text

231

Max128Text231


Indexes

Page 300

Max140Text231, 247, 248Message AdditionalPaymentInformation 29Message CaseStatusReport 59Message DebitAuthorisationResponse 105Message RequestToModifyPayment 156, 156Message ResolutionOfInvestigation 186

Max16Text231, 236, 236, 237, 237, 247, 248, 248, 248, 248, 248, 259, 259

Max256Text231

Max350Text232

Max35Text232, 233, 236, 236, 236, 236, 236, 236, 237, 237, 247, 247, 247, 247, 247, 247, 247, 247, 247, 247, 247, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 248, 259, 259, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260, 260Message AdditionalPaymentInformation 29, 29, 29, 29, 30, 30, 30Message CancelCaseAssignment 50, 50Message CaseStatusReport 59, 59, 59Message CaseStatusReportRequest 67, 68Message ClaimNonReceipt 74, 74, 75, 75Message DebitAuthorisationRequest 94, 94, 94, 94Message DebitAuthorisationResponse 104, 105Message NotificationOfCaseAssignment 115, 115, 115Message RejectCaseAssignment 127, 127Message RequestForDuplicateInstruction 133, 134Message RequestToCancelPayment 140, 140, 141, 141Message RequestToModifyPayment 155, 155, 155, 155, 155, 156, 156, 156, 156, 156Message ResolutionOfInvestigation 186, 186, 186, 187, 187Message UnableToApply 197, 197, 198, 198

Max70Text232, 233, 236, 236, 236, 237, 237, 259, 259, 259

MICIdentifier229

MissingCoverMessage ClaimNonReceipt 75

MissingOrIncorrectInformationMessage UnableToApply 198

NNameAndAddress2

247, 248


Indexes

Page 301

NationalityCode229

NewZealandNCCIdentifier229, 235

NonFinancialInstitutionIdentification1259

Number230

PParty1Choice

259

PartyIdentification1259Message AdditionalPaymentInformation 30, 30, 30, 30Message RequestToModifyPayment 156, 156, 156, 156

PartyIdentification1Choice247, 248

PaymentCancellationRejection1CodeMessage ResolutionOfInvestigation 186

PaymentComplementaryInformationMessage AdditionalPaymentInformation 29

PaymentInstructionExtractMessage AdditionalPaymentInformation 29Message ClaimNonReceipt 75Message DebitAuthorisationRequest 94Message RequestToCancelPayment 141Message RequestToModifyPayment 155Message ResolutionOfInvestigation 187Message UnableToApply 198

PaymentModificationRejection1CodeMessage ResolutionOfInvestigation 186

PaymentPurpose1CodeMessage RequestToModifyPayment 156

PaymentSchemeChoiceMessage RequestToModifyPayment 156

PercentageRate231


Indexes

Page 302

PersonIdentification2260

PortugueseNCCIdentifier229, 236

PostalAddress1236, 237, 259

PurposeChoiceMessage RequestToModifyPayment 156

RReferredDocumentAmount1Choice


RejectedCancellationJustificationMessage ResolutionOfInvestigation 186

RemittanceInformation3ChoiceMessage AdditionalPaymentInformation 29Message RequestToModifyPayment 156

ReportHeaderMessage CaseStatusReport 58Message CaseStatusReportRequest 67Message NotificationOfCaseAssignment 115

RequestedModificationMessage RequestToModifyPayment 155

RussianCentralBankIdentificationCodeIdentifier229, 236

SSimpleIdentificationInformation

233, 248

SmallNetworkIdentifier229, 236

SouthAfricanNCCIdentifier229, 236

SpanishDomesticInterbankingIdentifier230, 236


Indexes

Page 303

StructuredLongPostalAddress1247, 248

StructuredRemittanceInformation2Message AdditionalPaymentInformation 30Message RequestToModifyPayment 156

SWIFTServiceLevel2CodeMessage RequestToModifyPayment 155

SwissBCIdentifier230, 236

SwissSICIdentifier230, 236

UUKDomesticSortCodeIdentifier

230, 236

UnableToApplyIncorrectInfo1CodeMessage UnableToApply 198

UnableToApplyJustificationChoiceMessage UnableToApply 198

UnableToApplyMissingInfo1CodeMessage UnableToApply 198

UPICIdentifier230, 233

YYesNoIndicator

Message AdditionalPaymentInformation 29Message CancelCaseAssignment 50Message CaseStatusReport 59Message CaseStatusReportRequest 68Message ClaimNonReceipt 74, 75Message DebitAuthorisationRequest 94Message DebitAuthorisationResponse 105, 105Message NotificationOfCaseAssignment 115Message RejectCaseAssignment 127Message RequestForDuplicateInstruction 134Message RequestToCancelPayment 140Message RequestToModifyPayment 155Message ResolutionOfInvestigation 186, 186, 186Message UnableToApply 197, 198


Indexes

Page 304

ErrataDefinition for RejectionReason Code UKNWSee section Message: RejectCaseAssignment <camt.031.001.01> and subsection Message Items Description, 3.1. The Definition of the code UKNW in the table CaseAssignmentRejection1Code should read as follows.

Code Name Definition

UKNW UnknownCase Case has never been assigned before.


Errata

Page 305

Revision RecordRevision Date Author Description Sections affected

1.0 11/08/2006 ISO 20022 RA Initial version All


Revision Record

Page 306

investigations payments standards - exceptions and

Documents