Coduri Mesaje SWIFT

CGI Overview

MISSIONThe mission of the Common Global Implementation (CGI) initiative is to provide a forum for financial institutions (banks and bank associations) and non-financial institutions (corporates, corporate associations, vendors and market infrastructures) to progress various corporate-to-bank implementation topics on the use of ISO 20022 messages and to other related activities, in the payments domain. The overall objective of this group is to simplify implementation for corporate users and thereby to promote wider acceptance of ISO20022 as the common XML standard used between corporates and banks. This is achieved through consultation, collaboration and agreement on common implementation templates for relevant ISO 20022 financial messages, leading to their subsequent publication and promotion in order to attain widespread recognition and adoption.

IMPLEMENTATION TEMPLATESThe underlying CGI message implementation templates provide clear guidance, in terms of which XML fields are required, optional, bilaterally determined or not used from both a core message and local country rules perspective.

The local country rules have been based on the underlying local market requirements as this represents the lowest common denominator in terms of what data is required in order for the originating bank to make a valid payment. This means that all banks that have signed up to support a particular CGI message implementation template will be required to accept the information contained within the applicable Appendix where they support that service. For example, a generic approach to Thailand Withholding Tax has been agreed, but this will only have applicability to those banks that have agreed with the customer to support this service.

However, it should also be noted that some banks may be able to offer data enrichment services, whereby data that is already known by the bank would not necessarily need to be provided again by the originating corporate within the payment file (an example might be Charge Bearer). . This is something that will form part of bi-lateral implementation discussions between the bank and the customer.

Appendix will be created, as appropriate, based on the business requirements of a specific message.

HARMONISATIONIt should also be noted that the CGI message implementation template provides the opportunity to establish a generic harmonised multi-banking ISO 20022 XML message. However, this may not be the only implementation that banks will support. Some banks may be able to offer value added solutions that are over and above the core CGI message implementation template.

DATA CONTENT PRINCIPLEFinally, in order to establish a single generic harmonised message, the originator of the message may pass more information than is actually required for the message to be processed. Where the recipient may not actually require this surplus information, it will be viewed as data overpopulation and will be ignored. The model applies for both corporate to bank and bank to corporate messages. This concept of data overpopulation provides the core foundation to establishing a single generic harmonised template.

of 18

COMMON GLOBAL IMPLEMENTATION (CGI)Payment Status Report pain.002.001.03As of November 30, 2009

Driven by customer demand for multibank coordination of implementationsGlobal corporate, multi-banked, multi-payment type, multi-country implementations (mixed payables)Is intended specifically for global, multi-country, multi-bank and multi-instrument implementations that the participating

banks can commonly accept as ONE of their implementationsFocuses on the general message structure and then successful creation of individual transactions that can be executed

by the participating banksCan be published and has endorsement from appropriate communitiesActively engages corporate partnership

The common global implementation is not intended to:Focus on purely domestic or single instrument files (e.g. banks will still offer these)Serve as the sole map accepted by participating banks (e.g. participating banks will still be able to offer their value added

services and capabilities but can also offer this common implementation where desirable or requested by an appropriate customer)

Replace domestic banking convention in-country or bank servicing capabilities (e.g. these are different than agreeing on the format that can be commonly used)

Serve as an interbank map (e.g. participating banks will be able to create proper instructions and file formats for domestic clearing and settlement systems from this map)

COMMON GLOBAL IMPLEMENTATION GUIDELINES~The required elements in the CGI will be accepted by all CGI supporting banks. They define a standard set of data with agreed country/payment instrument qualifications.~Any data populated in a schema-defined optional field that is not required by an individual bank will be ignored and not stop processing of the message. This rule includes elements that are designated "Not Used" by the CGI. Bilateral documentation should specify where an "R" field will be ignored by a specific bank.~Where individual clients do not maintain a CGI-Required or Conditional element in their systems, they should consult with their bank(s) on the minimum of data elements required for that type of transaction. This could result in the need to add those data elements into the client's systems.~The following general attributes are assigned in the CGI and should be read in conjunction with the country/payment instrument rules produced for the CGI. If a country/payment instrument has not been addressed, the banks engaged by the client will work to try and agree on a common addition to the CGI country/payment instrument rules~Any of the data tags included in this guide will be accepted by any bank supporting the CGI. The bank will either use the tag for processing or ignore it.

of 18

ATTRIBUTESCODES TERM DEFINITIONS EXPLANATION

R Required Standard element for CGI; Required either by schema or CGI

This element is either mandatory in the schema or is a required by some or all of the CGI supporting banks. An "R" field may represent a piece of data that some of the banks do not need for processing, but have agreed that the client may send. Bilateral documentation should specify where an "R" field will be ignored by a specific bank.

C Conditional Standard element for CGI; Dependent upon a certain condition.

This element needs to be present when certain conditions apply. These fields are designated "C" with the condition specifically defined in the "RULES' column. These conditions include: -Presence based on a choice between elements or components which are shown to be mandatory in the schema, such as the choice between code and proprietary. -Presence based on whether a data element or component exists for that specific transaction, such as the presence of an ultimate debtor or ultimate creditor for that transaction. -Presence based on the requirements for a specific country and/or payment instrument.

BD Bilaterally Determined Standard element for CGI. Contents are bilaterally determined between client and bank

This is an element that an individual bank or client may require. The need to populate it will vary. For example, some banks may require the use of a branch identification code in countries where they have multiple branches and execute transactions through each of their branches.

Individual bank documentation should be consulted to determine when and how to populate a "BD" designated field.

XOR eXclusive Or Standard element for CGI. Contents are XOR either by the schema or CGI usage.

Select one or the other field, but not both

NU Not Used Not Used by CGI This element is not used by the CGI. The field may be present and will be ignored by receiving party of the message. The data fields are 'hidden' for concise presentation of guide.

REFERENCES TO ISO DOCUMENTATION[0..x] Optional Optional to schema for subcomponent;

may repeatOccurrence will note whether a subcomponent is repeating and number of occurences.

[1..1] Mandatory Mandatory to schema for subcomponent Occurrence will note whether a subcomponent is mandatory in the schema of the component.

Root Tag of messageLevel Component Tag; no data content

Component Tag; no data contentData Tag not used

of 18

CONTRIBUTORSBBVA Nordea CRG (Ikea, Wuerth, Fiat Group, Yara,

Utsit)Bank of America Merrill Lynch

RBS Cargill

BNP Paribas Santander OracleCitibank SEB GEDeutsche Bank Standard Chartered

BankDanish Bankers Association

HSBC SWIFTJPMC UK Payments

ASSUMPTIONS

-Tag length is dependent upon country clearing requirements and is not quoted in this document.

-This document addresses where the data is placed. It does not define the requirements for when the data must be present or the values to be contained.-The branch code of an agent should be explicitely stated I the component versus being combined with Clearing System Member ID when it is required.

-The CGI allows for inclusion of SEPA transactions based on CGI parameters which may be broader than SEPA guidelines.-Information captured under or is used explicitily for the applicable function and not to be reported to beneficiary as part of the payment.-The CGI country rules template represents the minimum requirements for each payment method within each country in order for the payment to be processed. It does - The population of or under or is depdendent upon the originator's usage of ISO 20022 code value in the External Code List in

-Truncation of data will be determined via bilateral agreement between customer and bank.-Duplicate checking will be determined via bilateral agreement between customer and bank.

-Standard XML version declaration must explicitly specify that XML v1.0 is being used. The tag should specify the appropriate namespace. Example:

of 18

Customer Payment Status Report pain.002.001.03ISO Published: April 2009Common Industry Agreement: As of November 30, 2009APPROVED BY CGI PLENARY: May 11, 2011

ISO Index No.

Or Message Item Tag Name Mult. Type Status RULES

0.0 Customer Payment Status Report [1..1] R 1.0 GroupHeader [1..1] R 1.1 MessageIdentification [1..1] Text R 1.2 CreationDateTime [1..1] DateTime R 1.3 InitiatingParty [0..1] R 9.1.12 Identification [0..1] R 9.1.13 {Or OrganisationIdentification [1..1] R The Sender of the Message identification

is sent either in or with = BANK; not both.

9.1.14 BICOrBEI [0..1] Identifier C Only used to identify the sender of Status Message - BANK (Bank BIC).

9.1.15 Other [0..n] C/R Conditional when Sender cannot be identified with .Required for Receiver of the Status Message.

9.1.16 Identification [1..1] Text R Used to identify the receiver of the Status Message - CUSTUsed to identify the sender of the Status Message when is not available - BANK

9.1.17 SchemeName [0..1] R 9.1.18 {{Or Code [1..1] Code R BANK: Sender of Status Message other

than BICCUST: Receiver of Status Message

2.0 OriginalGroupInformationAndStatus [1..1] R 2.1 OriginalMessageIdentification [1..1] Text R 2.2 OriginalMessageNameIdentification [1..1] Text R 2.4 OriginalNumberOfTransactions [0..1] Text BD If supplied by originator in the initiation

message, will be echoed back.

2.5 OriginalControlSum [0..1] Quantity BD If supplied by originator in the initiation message, will be echoed back.

V3 Implementation Guide

of 18

ISO Index No.


2.6 GroupStatus [0..1] Code C Required if reporting on a group level or combined group and transaction levels. Not Used if reporting at a transaction level only.

ACTC: Group onlyACCP: Group only and/or Consolidated statusACSP: Group only and/or Consolidated statusACWC: Group only and/or Consolidated statusPART: Group only and/or Consolidated statusPDNG: Group only and/or Consolidated statusRJCT: Group only and/or Consolidated status

2.7 StatusReasonInformation [0..n] BD Dependent upon bank's reporting capabilities based on Group Status codes.

2.9 Reason [0..1] BD 2.10 {Or Code [1..1] Code R Code required from External Code List. If

a bank's status code is supported other than a code from the External Code List, then the bank status code is shown under .

2.12 AdditionalInformation [0..n] Text BD 2.13 NumberOfTransactionsPerStatus [0..n] BD 2.14 DetailedNumberOfTransactions [1..1] Text R 2.15 DetailedStatus [1..1] Code R 2.16 DetailedControlSum [0..1] Quantity BD 3.0 OriginalPaymentInformationAndStatus [0..n] BD 3.1 OriginalPaymentInformationIdentification [1..1] Text R 3.4 PaymentInformationStatus [0..1] Code C Required if reporting on a payment level

or combined payment and transaction levels. Not Used if reporting at a transaction level only.

ACCP: Accepted technical, syntactical and profile; passed to back officeACSP: Accepted back office; passed to clearingACWC: Accepted with changePART: Partially accepted and rejected PDNG: Pending further processingRJCT: Rejection

3.5 StatusReasonInformation [0..n] BD 3.7 Reason [0..1] BD

of 18

ISO Index No.


3.8 {Or Code [1..1] Code R Code required from External Code List. If a bank's status reason code is supported other than a code from the External Code List, then the bank status code is shown under .

3.10 AdditionalInformation [0..n] Text BD 3.11 NumberOfTransactionsPerStatus [0..n] BD 3.12 DetailedNumberOfTransactions [1..1] Text R 3.13 DetailedStatus [1..1] Code R 3.14 DetailedControlSum [0..1] Quantity BD 3.15 TransactionInformationAndStatus [0..n] C Required if reporting on at the transaction

level, at the payment/transaction level, or the group/payment/transaction levels. Not Used if reporting at only a group or payment level.

3.16 StatusIdentification [0..1] Text BD 3.17 OriginalInstructionIdentification [0..1] Text BD 3.18 OriginalEndToEndIdentification [0..1] Text R 3.19 TransactionStatus [0..1] Code C Required if reporting on a transaction

level. Not Used if reporting only at a group or payment level.

ACCP: Accepted technical, syntactical and profile; passed to back officeACSP: Accepted back office; passed to clearingACWC: Accepted with changePDNG: Pending further processingRJCT: Rejection

3.20 StatusReasonInformation [0..n] BD 3.22 Reason [0..1] BD 3.23 {Or Code [1..1] Code R Code required from External Code List. If

a bank's status reason code is supported other than a code from the External Code List, then the bank status code is shown under .

3.25 AdditionalInformation [0..n] Text BD If banks support ACWC, and Requested Execution Date is changed, date may be reflected in this tag.

3.32 OriginalTransactionReference [0..1] BD Message elements, if populated, under Original Transaction Reference should contain the same value as the message elements of the original instruction

3.34 Amount [0..1] R

of 18

ISO Index No.


3.35 {Or InstructedAmount [1..1] Amount XOR 3.36 Or} EquivalentAmount [1..1] XOR 3.37 Amount [1..1] Amount R 3.38 CurrencyOfTransfer [1..1] Code R 3.41 RequestedExecutionDate [0..1] DateTime R Date in the original message 3.121 Debtor [0..1] R 9.1.0 Name [0..1] Text R 3.122 DebtorAccount [0..1] R 1.1.0 Identification [1..1] R 1.1.1 {Or IBAN [1..1] Identifier XOR 1.1.2 Or} Other [1..1] XOR 1.1.3 Identification [1..1] Text R 3.123 DebtorAgent [0..1] R 6.1.0 FinancialInstitutionIdentification [1..1] R 6.1.1 BIC [0..1] Identifier C Multiple Ids may be present if available.

One identification is required.

6.1.2 ClearingSystemMemberIdentifica [0..1] C Multiple Ids may be present if available. One identification is required.

6.1.3 ClearingSystemIdentification [0..1] R 6.1.6 MemberIdentification [1..1] Text R 6.1.19 Other [0..1] C Multiple Ids may be present if available.


6.1.20 Identification [1..1] Text R 3.125 CreditorAgent [0..1] C Dependent upon transaction type 6.1.0 FinancialInstitutionIdentification [1..1] R 6.1.1 BIC [0..1] Identifier C Multiple Ids may be present if available.


6.1.2 ClearingSystemMemberIdentifica [0..1] C Multiple Ids may be present if available. One identification is required.

6.1.3 ClearingSystemIdentification [0..1] R 6.1.6 MemberIdentification [1..1] Text R 6.1.19 Other [0..1] C Multiple Ids may be present if available.


6.1.20 Identification [1..1] Text R 3.127 Creditor [0..1] R 9.1.0 Name [0..1] Text R 3.128 CreditorAccount [0..1] C Dependent upon transaction type 1.1.0 Identification [1..1] R 1.1.1 {Or IBAN [1..1] Identifier XOR 1.1.2 Or} Other [1..1] XOR 1.1.3 Identification [1..1] Text R

of 18

ISO 20022 Payment and Status FlowSUPPORT OF ONLY ONE PAYMENT STATUS REPORT MESSAGE - FILE LEVEL:

1

2

RJCT: File Rejected

NOTES: The above workflow applies where a bank undertakes file level validation and reports the status at a Group Header level only. A separate payment and transaction acknowledgement will then follow. Where file level validation is performed by the receiving bank, an appropriate code will be selected based on the level of processing undertaken. Where a bank supports a file level acknowledgement, only one will be issued.

ACTC: Accepted Technical Validation (Applies only where the bank provides an initial acknowledgment at Group Header level).

3 ACCP: Accepted (After technical and profile checks)

4 ACWC: Accepted with Change

5 PART: Partial Acceptance

6 PDNG: Pending

In Country Clearing System

1 2 3 4 5 6

Customer Back Office

In-Country Bank Processing Systems

Bank Server

Bank Channel Application

Or Agreed Connectivity

Method

of 18

SUPPORT OF PAYMENT AND TRANSACTION STATUS REPORT MESSAGE - ONE OR MORE MESSAGES:

1 3

1

3

RJCT: Payment or Transaction Rejected

Notes: The second workflow considers payment and transaction level reporting. Where transaction level validation is performed by the receiving bank, an appropriate code will be selected based on the level of processing undertaken. Where a bank supports a transaction level acknowledgement, you may receive more than one, as the bank may generate a status update based on the various stages of internal processing. In terms of the workflow, ACSP will be the final status code before a transaction is physically posted to a bank statement.


ACCP: Accepted (After technical and profile checks)

4 4 ACWC: Accepted with Change

5

6 PDNG: Pending

7

7 ACSP: Accepted back office, including any additional profile checks and passed to clearing.



Bank Server



Method

PART: Partial Acceptance: File or Payment level 5 6

of 18

SUPPORT OF CONSOLIDATED STATUS REPORT MESSAGE:

1

4

RJCT: File, Payment or Transaction Rejected

Notes: This final workflow considers where a bank issues a single consolidated acknowledgement that reports on the file, payment and underlying transactions depending on the level of processing that has been completed. For example, it may not be possible to report at a payment or transaction level where a file is rejected. Where transaction level validation is performed by the receiving bank, an appropriate code will be selected based on the level of processing undertaken.

ACCP: Accepted (After technical and profile checks)

5

ACWC: Accepted with Change

6 PDNG: Pending

7 ACSP: Accepted back office, including any additional profile checks and passed to clearing.

3

PART: Partial Acceptance: File or Payment level

1 4 5 6 7



Bank Server




Method

3

of 18

2.12 STATUS REASON CODES

NOTE: Codes shown in red text are codes that are in the process of being submitted through ISO 20022 External Code maintenance process.

CategoryB2C/Interb Code Name Definition Usage

Profile B2C AC01 IncorrectAccountNumber Format of the account number specified is not correct. CHANGE: Account number invalid or missing

Generic usage if cannot specify between debit or credit account

Profile B2C AC02 InvalidDebtorAccountNumber Debtor account number invalid or missingProfile B2C AC03 InvalidCreditorAccountNumber Creditor account number invalid or missing

Profile B2C AC04 ClosedAccountNumber Account number specified has been closed on the Receiver's books


Profile B2C AC05 ClosedDebtorAccountNumber Debtor account number closedProfile B2C AC07 ClosedCreditorAccountNumber Creditor account number closedProfile B2C AC06 BlockedAccount Account specified is blocked, prohibiting

posting of transactions against it.Profile B2C AC08 InvalidBranchCode Branch code is invalid or missingProfile B2C AC09 InvalidAccountCurrency Account currency is invalid or missingProfile B2C AC10 InvalidDebtorAccountCurrency Debtor account currency is invalid or missing

Profile B2C AC11 InvalidCreditorAccountCurrency Creditor account currency is invalid or missing

TXN B2C AC12 InvalidAccountType Account type missing or invalid Generic usage if cannot specify between group and payment information levels

TXN B2C AC13 InvalidDebtorAccountType Debtor account type missing or invalidTXN B2C AC14 InvalidCreditorAccountType Creditor account type missing or invalid

AG01 TransactionForbidden Transaction forbidden on this type of account (formerly NoAgreement)

AG02 InvalidBankOperationCode Bank Operation code specified in the message is not valid for receiver

Profile B2C AG03 TransactionNotSupported Transaction type not supported/authorized on this account

TXN B2C AG04 InvalidAgentCountry Agent country code is missing or invalid Generic usage if cannot specify between group and payment information levels

TXN B2C AG05 InvalidDebtorAgentCountry Debtor agent country code is missing or invalid

TXN B2C AG06 InvalidCreditorAgentCountry Creditor agent country code is missing or invalid

TXN B2C AG07 UnsuccesfulDirectDebit Debtor account cannot be debited for a generic reason

Code value may be used in general purposes and as a replacement for AM04 if debtor bank does not reveal its customer's insufficient funds for privacy reasons

TXN B2C AG08 InvalidAccessRights Transaction failed due to invalid or missing user or access right

of 18

TXN B2C AM01 ZeroAmount Specified message amount is equal to zero

TXN B2C AM02 NotAllowedAmount Specific transaction/message amount is greater than allowed maximum

TXN B2C AM13 AmountExceedsClearingSystemLimit Transaction amount exceeds limits set by clearing system

TXN B2C AM14 AmountExceedsAgreedLimit Transaction amount exceeds limits agreed between bank and client

TXN B2C AM12 InvalidAmount Amount is invalid or missingTXN B2C AM03 NotAllowedCurrency Specified message amount is an non

processable currency outside of existing agreement

TXN B2C AM11 InvalidTransactionCurrency Transaction currency is invalid or missingTXN B2C AM04 InsufficientFunds Amount of funds available to cover specified

message amount is insufficient.AM05 Duplication Duplication

TXN B2C AM06 TooLowAmount Specified transaction amount is less than agreed minimum.

TXN B2C AM15 AmountBelowClearingSystemMinimum Transaction amount below minimum set by clearing system

AM07 BlockedAmount Amount of funds available to cover specified message amount is insufficient.

AM09 WrongAmount Amount received is not the amount agreed or expected

AM10 InvalidControlSum Sum of instructed amounts does not equal the control sum.

Generic usage if cannot specify between group and payment information levels

Control B2C AM16 InvalidGroupControlSum Control Sum at the Group level is invalidControl B2C AM17 InvalidPaymentInfoControlSum Control Sum at the Payment Information level

is invalidControl B2C AM18 InvalidNumberOfTransactions Number of transactions is invalid or missing Generic usage if cannot specify

between group and payment information levels

Control B2C AM19 InvalidGroupNumberOfTransactions Number of transactions at the Group level is invalid or missing

Control B2C AM20 InvalidPaymentInfoNumberOfTransactions Number of transactions at the Payment Information level is invalid

BE01 InconsistenWithEndCustomer Identification of end customer is not consistent with associated account number. (formerly CreditorConsistency).

TXN B2C BE04 MissingCreditorAddress Specification of creditor's address, which is required for payment, is missing/not correct (formerly IncorrectCreditorAddress).

BE05 UnrecognisedInitiatingParty Party who initiated the message is not recognised by the end customer

BE06 UnknownEndCustomer End customer specified is not known at associated Sort/National Bank Code or does no longer exist in the books

of 18

TXN B2C BE07 MissingDebtorAddress Specification of debtor's address, which is required for payment, is missing/not correct.

TXN B2C BE08 MissingDebtorName Debtor name is missingTXN B2C BE22 MissingCreditorName Creditor name is missingTXN B2C BE09 InvalidCountry Country code is missing or Invalid Generic usage if cannot specifically

identify debtor or creditor

TXN B2C BE10 InvalidDebtorCountry Debtor country code is missing or InvalidTXN B2C BE11 InvalidCreditorCountry Creditor country code is missing or InvalidTXN B2C BE12 InvalidCountryOfResidence Country code of residence is missing or Invalid Generic usage if cannot specifically


TXN B2C BE13 InvalidDebtorCountryOfResidence Country code of debtor's residence is missing or Invalid

TXN B2C BE14 InvalidCreditorCountryOfResidence Country code of creditor's residence is missing or Invalid

TXN B2C BE15 InvalidIdentificationCode Identification code missing or invalid Generic usage if cannot specifically identify debtor or creditor

TXN B2C BE16 InvalidDebtorIdentificationCode Debtor or Ultimate Debtor identification code missing or invalid

TXN B2C BE17 InvalidCreditorIdentificationCode Creditor or Ultimate Creditor identification code missing or invalid

TXN B2C BE18 InvalidContactDetails Contact details missing or invalidTXN B2C BE19 InvalidChargeBearerCode Charge bearer code for transaction type is

invalidTXN B2C BE20 InvalidNameLength Name length exceeds local rules for payment

type.TXN B2C BE21 MissingName Name missing or invalid Generic usage if cannot specifically


TXN B2C CURR IncorrectCurrency Currency of the payment is incorrect

CUST RequestedByCustomer Cancellation requested by the DebtorDS0A DataSignRequested Data signature is required.DS0B UnknownDataSignFormat Data signature for the format is not available or

invalid.DS0C SignerCertificateRevoked The signer certificate is revoked.DS0D SignerCertificateNotValid The signer certificate is not valid (revoked or

not active).DS0E IncorrectSignerCertificate The signer certificate is not present.DS0F SignerCertificationAuthoritySignerNotValid The authority of the signer certification sending

the certificate is unknown.DS0G NotAllowedPayment Signer is not allowed to sign this operation

type.DS0H NotAllowedAccount Signer is not allowed to sign for this account.

DS0K NotAllowedNumberOfTransaction The number of transaction is over the number allowed for this signer.

DS10 Signer1CertificateRevoked The certificate is revoked for the first signer.

of 18

DS11 Signer1CertificateNotValid The certificate is not valid (revoked or not active) for the first signer.

DS12 IncorrectSigner1Certificate The certificate is not present for the first signer.

DS13 SignerCertificationAuthoritySigner1NotValid The authority of signer certification sending the certificate is unknown for the first signer.

DS20 Signer2CertificateRevoked The certificate is revoked for the second signer.

DS21 Signer2CertificateNotValid The certificate is not valid (revoked or not active) for the second signer.

DS22 IncorrectSigner2Certificate The certificate is not present for the second signer.

DS23 SignerCertificationAuthoritySigner2NotValid The authority of signer certification sending the certificate is unknown for the second signer.

TXN B2C DT01 InvalidDate Invalid date (eg, wrong settlement date) or missing

Control B2C DT02 InvalidCreationDate Invalid creation date and time in Group Header (eg, historic date)

TXN B2C DT03 InvalidNonProcessingDate Invalid non bank processing date (eg, weekend or local public holiday)

TXN B2C DT04 FutureDateNotSupported Future date not supportedTXN B2C DT05

InvalidCutOffDate

Associated message, payment information block or transaction was received after agreed processing cut-off date, i.e., date in the past.

TXN B2C DT06ExecutionDateChanged

Execution Date has been modified in order for transaction to be processed

Control B2C DUPL DuplicatePayment Payment is a duplicate of another payment

Control B2C DU01 DuplicateMessageID Message Identification is not unique.Control B2C DU02 DuplicatePaymentInformationID Payment Information Block is not unique.Control B2C DU03 DuplicateTransaction Transaction is not unique.Control B2C DU04 DuplicateEndToEndID End To End ID is not unique.Control B2C DU05 DuplicateInstructionID Instruction ID is not unique.

ED01 CorrespondentBankNotPossible Correspondent bank not possible.ED03 BalanceInfoRequest Balance of payments complementary info is

requestedED05 SettlementFailed Settlement of the transaction has failed.

Control B2C FF01 Invalid File Format File Format incomplete or invalidControl B2C FF02 SyntaxError Syntax error reason is provided as narrative

information in the additional reason information.

TXN B2C FF03 InvalidPaymentTypeInformation Payment Type Information is missing or invalid Generica usage if cannot specify Service Level or Local Instrument code

TXN B2C FF04 InvalidServiceLevelCode Service Level code is missing or invalidTXN B2C FF05 InvalidLocalInstrumentCode Local Instrument code is missing or invalid

TXN B2C FF06 InvalidCategoryPurposeCode Category Purpose code is missing or invalid

of 18

TXN B2C FF07 InvalidPurpose Purpose is missing or invalidTXN B2C FF08 InvalidEndToEndId End to End Id missing or invalidTXN B2C FF09 InvalidChequeNumber Cheque number missing or invalidTXN B2C FF10 BankSystemProcessingError File or transaction cannot be processed due to

technical issues at the bank sideMD01 NoMandate No MandateMD02 MissingMandatoryInformationIn Mandate Mandate related information data required by

the scheme is missing.MD05 CollectionNotDue Creditor or creditor's agent should not have

collected the direct debitMD06 RefundRequestByEndCustomer Return of funds requested by end customer

MD07 EndCustomerDeceased End customer is deceased.MS02 NotSpecifiedReasonCustomer Generated Reason has not been specified by end

customerMS03 NotSpecifiedReasonAgent Generated Reason has not been specified by agent.

NARR Narrative Reason is provided as narrative information in the additional reason information.

RC01 BankIdentifierIncorrect Bank Identifier coe specified in the message has an incorrect format (formerly IncorrectFormatForRoutingCode).

TXN B2C RC02 InvalidBankIdentifier Bank identifier is invalid or missing Generic usage if cannot specify between debit or credit account

TXN B2C RC03 InvalidDebtorBankIdentifier Debtor bank identifier is invalid or missing

TXN B2C RC04 InvalidCreditorBankIdentifier Creditor bank identifier is invalid or missing

TXN B2C RC05 InvalidBICIdentifier BIC identifier is invalid or missing Generic usage if cannot specify between debit or credit account

TXN B2C RC06 InvalidDebtorBICIdentifier Debtor BIC identifier is invalid or missing

TXN B2C RC07 InvalidCreditorBICIdentifier Creditor BIC identifier is invalid or missing

TXN B2C RC08 InvalidClearingSystemMemberIdentifier ClearingSystemMemberidentifier is invalid or missing


TXN B2C RC09 InvalidDebtorClearingSystemMemberIdentifier

Debtor ClearingSystemMember identifier is invalid or missing

TXN B2C RC10 InvalidCreditorClearingSystemMemberIdentifier

Creditor ClearingSystemMember identifier is invalid or missing

TXN B2C RC11 InvalidIntermediaryAgent Intermediary Agent is invalid or missing

TXN B2C RC12 MissingCreditorSchemeId Creditor Scheme Id is invalid or missing

RF01 NotUniqueTransactionReference Transaction reference is not unique within the message.

of 18

RR01 Missing Debtor Account or Identification Specification of the debtors account or unique identification needed for reasons of regulatory requirements is insufficient or missing

RR02 Missing Debtor Name or Address Specification of the debtors name and/or address needed for regulatory requirements is insufficient or missing.

RR03 Missing Creditor Name or Address Specification of the creditors name and/or address needed for regulatory requirements is insufficient or missing.

RR04 Regulatory Reason Regulatory ReasonTXN B2C RR05 RegulatoryInformationInvalid Regulatory or Central Bank Reporting

information missing, incomplete or invalid.TXN B2C RR06 TaxInformationInvalid Tax information missing, incomplete or invalid.

TXN B2C RR07 RemittanceInformationInvalid Remittance information structure does not comply with rules for payment type.

TXN B2C RR08 RemittanceInformationTruncated Remittance information truncated to comply with rules for payment type.

TXN B2C RR09 InvalidStructuredCreditorReference Structured creditor reference invalid or missing.

TXN B2C RR10 InvalidCharacterSet Character set supplied not valid for the country and payment type.

TXN B2C RR11 InvalidDebtorAgentServiceID Invalid or missing identification of a bank proprietary service.

TXN B2C RR12 InvalidPartyID Invalid or missing identification required within a particular country or payment type.

SL01 Specific Service offered by Debtor Agent Due to specific service offered by the Debtor Agent

SL02 Specific Service offered by Creditor Agent Due to specific service offered by the Creditor Agent

TXN B2C TM01 InvalidCutOffTime Associated message, payment information block or transaction was received after agreed processing cut-off time.

CHANGE CONTROL -- Customer Payment Status Report pain.002.001.03

Notation of recent change

REVISION DATE XML TAG NOTES

CHANGE REQUESTED BY

CHANGE DOCUMENTED

BY30-Oct-09 Inclusion for proper placement of BICorBEI for sender of message CGI Oct-09 Mtg SColles

30-Oct-09 Changed note that Bank Id should not be BIC CGI Oct-09 Mtg SColles20-Nov-09 Updated Overview contents and code values CGI Oct-09 Mtg SColles30-Dec-09 Updated Rule to include ACTC CGI Dec-09 Mtg SColles30-Dec-09 Updated Rule DDobbing SColles30-Dec-09 Updated Rule DDobbing SColles30-Dec-09 Updated Rule DDobbing SColles28-Jul-10 Update of CGI Logo and 'Data Content Principle' CGI Work Group SColles

11-May-11 Approved by CGI Plenary21-Nov-12 Removed Rows 174-176 which were duplicated entries JPMChase SColles

CGI Overview Overview for Payment Status V3pain.002.001.03Message FlowStatus Reason CodesChange Control

Documents

Coduri Mesaje SWIFT