You are on page 1of 18

CGI Overview

MISSION
The 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 TEMPLATES
The 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.

HARMONISATION
It 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 PRINCIPLE


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

COMMON GLOBAL IMPLEMENTATION (CGI)


Payment Status Report pain.002.001.03
As of November 30, 2009

Driven by customer demand for multibank coordination of implementations

Global

corporate, multi-banked, multi-payment type, multi-country implementations (mixed payables)


intended specifically for global, multi-country, multi-bank and multi-instrument implementations that the participating
banks can commonly accept as ONE of their implementations
Focuses on the general message structure and then successful creation of individual transactions that can be executed
by the participating banks
Can be published and has endorsement from appropriate communities
Actively engages corporate partnership
Is

The common global implementation is not intended to:

Focus

on purely domestic or single instrument files (e.g. banks will still offer these)
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)
Serve

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.

Page 2 of 18

ATTRIBUTES
CODES
R

BD

TERM
Required

Conditional

DEFINITIONS
EXPLANATION
Standard element for CGI; Required either This element is either mandatory in the schema or is a required by some or
by schema or CGI
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.
Standard element for CGI; Dependent upon This element needs to be present when certain conditions apply. These fields
a certain condition.
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.

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

NU

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

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


Optional
Optional to schema for subcomponent;
[0..x]
may repeat
Mandatory
Mandatory to schema for subcomponent
[1..1]

Occurrence will note whether a subcomponent is repeating and number of


occurences.
Occurrence will note whether a subcomponent is mandatory in the schema of
the component.

Root Tag of message


Level Component Tag; no data content
Component Tag; no data content
Data Tag not used

Page 3 of 18

CONTRIBUTORS
BBVA
Bank of America
Merrill Lynch
BNP Paribas
Citibank
Deutsche Bank
HSBC
JPMC

Nordea
RBS
Santander
SEB
Standard Chartered
Bank

CRG (Ikea, Wuerth, Fiat Group, Yara,


Utsit)
Cargill
Oracle
GE
Danish Bankers Association
SWIFT
UK Payments

ASSUMPTIONS
-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 <Document> tag should specify the appropriate namespace. Example:
<?xml version="1.0" encoding="UTF-8" ?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
-Tag length is dependent upon country clearing requirements and is not quoted in this document.
-The branch code of an agent should be explicitely stated I the <BrnchId> component versus being combined with Clearing System Member ID when it is required.
-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 CGI allows for inclusion of SEPA transactions based on CGI parameters which may be broader than SEPA guidelines.
-Information captured under <RegulatoryReporting> or <Tax> 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 <Cd> or <Prtry> under <CtgyPurp> or <Purp> is depdendent upon the originator's usage of ISO 20022 code value in the External Code List in <Cd>

Page 4 of 18

Customer Payment Status Report pain.002.001.03


ISO Published: April 2009
Common Industry Agreement: As of November 30, 2009
APPROVED BY CGI PLENARY: May 11, 2011
V3 Implementation Guide

ISO
Index
No.
0.0
1.0
1.1
1.2
1.3
9.1.12
9.1.13

Or

{Or

Message Item

Tag Name

Mult.

Customer Payment Status Report


GroupHeader
MessageIdentification
CreationDateTime
InitiatingParty
Identification
OrganisationIdentification

<CstmrPmtStsRpt>
<GrpHdr>
<MsgId>
<CreDtTm>
<InitgPty>
<Id>
<OrgId>

[1..1]
[1..1]
[1..1]
[1..1]
[0..1]
[0..1]
[1..1]

Type

Text
DateTime

Status

R
R
R
R
R
R
R

9.1.14

BICOrBEI

<BICOrBEI>

[0..1]

9.1.15

Other

<Othr>

[0..n]

Identification

<Id>

[1..1]

Text

SchemeName
Code

<SchmeNm>
<Cd>

[0..1]
[1..1]

Code

R
R

<OrgnlGrpInfAndSts>
<OrgnlMsgId>
<OrgnlMsgNmId>
<OrgnlNbOfTxs>

[1..1]
[1..1]
[1..1]
[0..1]

Text
Text
Text

R
R
R
BD

<OrgnlCtrlSum>

[0..1]

Quantity

BD

9.1.16

9.1.17
9.1.18

2.0
2.1
2.2
2.4

2.5

{{Or

OriginalGroupInformationAndStatus
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalNumberOfTransactions

OriginalControlSum

Identifier

Page 5 of 18

RULES

The Sender of the Message identification


is sent either in <BICorBEI> or <Othr>
with <SchmeNm><Cd> = BANK; not
both.

Only used to identify the sender of Status


Message - BANK (Bank BIC).

C/R

Conditional when Sender cannot be


identified with <BICorBEI>.
Required for Receiver of the Status
Message.
Used to identify the receiver of the Status
Message - CUST
Used to identify the sender of the Status
Message when <BICorBEI> is not
available - BANK
BANK: Sender of Status Message other
than BIC
CUST: Receiver of Status Message

If supplied by originator in the initiation


message, will be echoed back.
If supplied by originator in the initiation
message, will be echoed back.

ISO
Index
No.

Or

2.6

GroupStatus

2.7

2.9
2.10

2.12
2.13
2.14
2.15
2.16
3.0
3.1
3.4

Message Item

StatusReasonInformation

{Or

Reason
Code

AdditionalInformation
NumberOfTransactionsPerStatus
DetailedNumberOfTransactions
DetailedStatus
DetailedControlSum
OriginalPaymentInformationAndStatus
OriginalPaymentInformationIdentification
PaymentInformationStatus

Tag Name

<GrpSts>

Mult.

Type

Status

RULES

[0..1]

Code

Required if reporting on a group level or


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

<StsRsnInf>

[0..n]

<Rsn>
<Cd>

[0..1]
[1..1]

<AddtlInf>
<NbOfTxsPerSts>
<DtldNbOfTxs>
<DtldSts>
<DtldCtrlSum>
<OrgnlPmtInfAndSts>
<OrgnlPmtInfId>
<PmtInfSts>

[0..n]
[0..n]
[1..1]
[1..1]
[0..1]
[0..n]
[1..1]
[0..1]

BD

Code

Text
Text
Code
Quantity
Text
Code

BD
R

BD
BD
R
R
BD
BD
R
C

ACTC: Group only


ACCP: Group only and/or Consolidated
status
ACSP: Group only and/or Consolidated
status
ACWC: Group only and/or Consolidated
status
PART: Group only and/or Consolidated
status
PDNG: Group only and/or Consolidated
status
RJCT: Group only and/or Consolidated
status
Dependent upon bank's reporting
capabilities based on Group Status codes.

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

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 office
ACSP: Accepted back office; passed to
clearing
ACWC: Accepted with change
PART: Partially accepted and rejected
PDNG: Pending further processing
RJCT: Rejection

3.5
3.7

StatusReasonInformation
Reason

<StsRsnInf>
<Rsn>

[0..n]
[0..1]

BD
BD
Page 6 of 18

ISO
Index
No.
3.8

Or

{Or

Message Item

Code

3.10
3.11
3.12
3.13
3.14
3.15

AdditionalInformation
NumberOfTransactionsPerStatus
DetailedNumberOfTransactions
DetailedStatus
DetailedControlSum
TransactionInformationAndStatus

3.16
3.17
3.18
3.19

StatusIdentification
OriginalInstructionIdentification
OriginalEndToEndIdentification
TransactionStatus

Tag Name

Mult.

Type

Status

RULES

<Cd>

[1..1]

Code

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

<AddtlInf>
<NbOfTxsPerSts>
<DtldNbOfTxs>
<DtldSts>
<DtldCtrlSum>
<TxInfAndSts>

[0..n]
[0..n]
[1..1]
[1..1]
[0..1]
[0..n]

Text

BD
BD
R
R
BD
C

<StsId>
<OrgnlInstrId>
<OrgnlEndToEndId>
<TxSts>

[0..1]
[0..1]
[0..1]
[0..1]

Text
Text
Text
Code

Text
Code
Quantity

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

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 office
ACSP: Accepted back office; passed to
clearing
ACWC: Accepted with change
PDNG: Pending further processing
RJCT: Rejection

3.20
3.22
3.23

3.25

3.32

3.34

{Or

StatusReasonInformation
Reason
Code

AdditionalInformation

OriginalTransactionReference

Amount

<StsRsnInf>
<Rsn>
<Cd>

[0..n]
[0..1]
[1..1]

Code

BD
BD
R

<AddtlInf>

[0..n]

Text

BD

<OrgnlTxRef>

[0..1]

BD

<Amt>

[0..1]

R
Page 7 of 18

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 <AddtlInf>.
If banks support ACWC, and Requested
Execution Date is changed, date may be
reflected in this tag.
Message elements, if populated, under
Original Transaction Reference should
contain the same value as the message
elements of the original instruction

ISO
Index
No.
3.35
3.36
3.37
3.38
3.41
3.121
9.1.0
3.122
1.1.0
1.1.1
1.1.2
1.1.3
3.123
6.1.0
6.1.1

Or

{Or
Or}

{Or
Or}

Message Item

InstructedAmount
EquivalentAmount
Amount
CurrencyOfTransfer
RequestedExecutionDate
Debtor
Name
DebtorAccount
Identification
IBAN
Other
Identification
DebtorAgent
FinancialInstitutionIdentification
BIC

Tag Name

<InstdAmt Ccy="AAA">
<EqvtAmt>
<Amt Ccy="AAA">
<CcyOfTrf>
<ReqdExctnDt>
<Dbtr>
<Nm>
<DbtrAcct>
<Id>
<IBAN>
<Othr>
<Id>
<DbtrAgt>
<FinInstnId>
<BIC>

Mult.

[1..1]
[1..1]
[1..1]
[1..1]
[0..1]
[0..1]
[0..1]
[0..1]
[1..1]
[1..1]
[1..1]
[1..1]
[0..1]
[1..1]
[0..1]

6.1.2

ClearingSystemMemberIdentifica <ClrSysMmbId>

[0..1]

6.1.3
6.1.6
6.1.19

ClearingSystemIdentification <ClrSysId>
<MmbId>
MemberIdentification
<Othr>
Other

[0..1]
[1..1]
[0..1]

6.1.20
3.125
6.1.0
6.1.1

Identification
CreditorAgent
FinancialInstitutionIdentification
BIC

<Id>
<CdtrAgt>
<FinInstnId>
<BIC>

[1..1]
[0..1]
[1..1]
[0..1]

6.1.2

ClearingSystemMemberIdentifica <ClrSysMmbId>

[0..1]

6.1.3
6.1.6
6.1.19

ClearingSystemIdentification <ClrSysId>
<MmbId>
MemberIdentification
<Othr>
Other

[0..1]
[1..1]
[0..1]

<Id>
<Cdtr>
<Nm>
<CdtrAcct>
<Id>
<IBAN>
<Othr>
<Id>

[1..1]
[0..1]
[0..1]
[0..1]
[1..1]
[1..1]
[1..1]
[1..1]

6.1.20
3.127
9.1.0
3.128
1.1.0
1.1.1
1.1.2
1.1.3

{Or
Or}

Identification
Creditor
Name
CreditorAccount
Identification
IBAN
Other
Identification

Type

Amount
Amount
Code
DateTime
Text

Identifier
Text

Identifier

Status

XOR
XOR
R
R
R
R
R
R
R
XOR
XOR
R
R
R
C

Text

Text

Identifier

R
R
C

R
C
R
C

Text

Text
Text

Identifier
Text

Page 8 of 18

R
R
C

R
R
R
C
R
XOR
XOR
R

RULES

Date in the original message

Multiple Ids may be present if available.


One identification is required.
Multiple Ids may be present if available.
One identification is required.

Multiple Ids may be present if available.


One identification is required.

Dependent upon transaction type


Multiple Ids may be present if available.
One identification is required.
Multiple Ids may be present if available.
One identification is required.

Multiple Ids may be present if available.


One identification is required.

Dependent upon transaction type

ISO 20022 Payment and Status Flow


SUPPORT OF ONLY ONE PAYMENT STATUS REPORT MESSAGE - FILE LEVEL:

Bank Channel
Application

Customer
Back Office

Or Agreed
Connectivity
Method

RJCT: File Rejected

ACTC: Accepted Technical Validation (Applies only


where the bank provides an initial acknowledgment at
Group Header level).

ACCP: Accepted (After technical and profile checks)

ACWC: Accepted with Change

PART: Partial Acceptance

PDNG: Pending

In-Country Bank
Processing Systems

Bank
Server

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.

Page 9 of 18

In Country Clearing
System

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

Customer
Back Office

Or Agreed
Connectivity
Method

RJCT: Payment or Transaction Rejected

ACCP: Accepted (After technical and profile checks)

ACWC: Accepted with Change

PART: Partial Acceptance: File or Payment level

PDNG: Pending

In-Country Bank
Processing Systems

Bank
Server

ACSP: Accepted back office, including any additional profile


checks and passed to clearing.
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.

Page 10 of 18

In Country Clearing
System

SUPPORT OF CONSOLIDATED STATUS REPORT MESSAGE:


Bank Channel
Application

Customer
Back Office

Or Agreed
Connectivity
Method

RJCT: File, Payment or Transaction Rejected

ACCP: Accepted (After technical and profile checks)

ACWC: Accepted with Change

PART: Partial Acceptance: File or Payment level

In-Country Bank
Processing Systems

Bank
Server

PDNG: Pending

ACSP: Accepted back office, including any additional profile


checks and passed to clearing.

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.

Page 11 of 18

In Country Clearing
System

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.

Category
Profile

B2C/
Interb
B2C

Code
AC01

Name
IncorrectAccountNumber

Definition
Usage
Format of the account number specified is not Generic usage if cannot specify
correct. CHANGE: Account number invalid or between debit or credit account
missing
Debtor account number invalid or missing
Creditor account number invalid or missing

Profile

B2C

Profile

B2C

AC02
AC03

InvalidDebtorAccountNumber
InvalidCreditorAccountNumber

Profile

B2C

AC04

ClosedAccountNumber

Profile

B2C

Profile

B2C

Profile

B2C

AC05
AC07
AC06

ClosedDebtorAccountNumber
ClosedCreditorAccountNumber
BlockedAccount

Profile

B2C

Profile

B2C

Profile

B2C

AC08
AC09
AC10

InvalidBranchCode
InvalidAccountCurrency
InvalidDebtorAccountCurrency

Account number specified has been closed on Generic usage if cannot specify
the Receiver's books
between debit or credit account
Debtor account number closed
Creditor account number closed
Account specified is blocked, prohibiting
posting of transactions against it.
Branch code is invalid or missing
Account currency is invalid or missing
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

TXN

B2C

TXN

B2C

AC13 InvalidDebtorAccountType
AC14 InvalidCreditorAccountType
AG01 TransactionForbidden
AG02 InvalidBankOperationCode

Profile

B2C

AG03 TransactionNotSupported

TXN

B2C

AG04 InvalidAgentCountry

TXN

B2C

AG05 InvalidDebtorAgentCountry

TXN

B2C

AG06 InvalidCreditorAgentCountry

TXN

B2C

AG07 UnsuccesfulDirectDebit

TXN

B2C

AG08 InvalidAccessRights

Generic usage if cannot specify


between group and payment
information levels

Debtor account type missing or invalid


Creditor account type missing or invalid
Transaction forbidden on this type of account
(formerly NoAgreement)
Bank Operation code specified in the message
is not valid for receiver
Transaction type not supported/authorized on
this account
Agent country code is missing or invalid
Generic usage if cannot specify
between group and payment
information levels
Debtor agent country code is missing or invalid
Creditor agent country code is missing or
invalid
Debtor account cannot be debited for a generic Code value may be used in general
reason
purposes and as a replacement for
AM04 if debtor bank does not reveal
its customer's insufficient funds for
privacy reasons
Transaction failed due to invalid or missing
user or access right
Page 12 of 18

TXN

B2C

AM01 ZeroAmount

Specified message amount is equal to zero

TXN

B2C

AM02 NotAllowedAmount

TXN

B2C

AM13 AmountExceedsClearingSystemLimit

TXN

B2C

AM14 AmountExceedsAgreedLimit

TXN

B2C

TXN

B2C

AM12 InvalidAmount
AM03 NotAllowedCurrency

TXN

B2C

AM11 InvalidTransactionCurrency

Specific transaction/message amount is


greater than allowed maximum
Transaction amount exceeds limits set by
clearing system
Transaction amount exceeds limits agreed
between bank and client
Amount is invalid or missing
Specified message amount is an non
processable currency outside of existing
agreement
Transaction currency is invalid or missing

TXN

B2C

AM04 InsufficientFunds

TXN

B2C

AM05 Duplication
AM06 TooLowAmount

TXN

B2C

AM15 AmountBelowClearingSystemMinimum
AM07 BlockedAmount
AM09 WrongAmount
AM10 InvalidControlSum

Control

B2C

Control

B2C

AM16 InvalidGroupControlSum
AM17
InvalidPaymentInfoControlSum

Control

B2C

AM18 InvalidNumberOfTransactions

Control

B2C

AM19 InvalidGroupNumberOfTransactions

Control

B2C

AM20 InvalidPaymentInfoNumberOfTransactions

TXN

B2C

BE01

InconsistenWithEndCustomer

BE04

MissingCreditorAddress

BE05

UnrecognisedInitiatingParty

BE06

UnknownEndCustomer

Amount of funds available to cover specified


message amount is insufficient.
Duplication
Specified transaction amount is less than
agreed minimum.
Transaction amount below minimum set by
clearing system
Amount of funds available to cover specified
message amount is insufficient.
Amount received is not the amount agreed or
expected
Sum of instructed amounts does not equal the
control sum.

Generic usage if cannot specify


between group and payment
information levels

Control Sum at the Group level is invalid


Control Sum at the Payment Information level
is invalid
Number of transactions is invalid or missing
Generic usage if cannot specify
between group and payment
information levels
Number of transactions at the Group level is
invalid or missing
Number of transactions at the Payment
Information level is invalid
Identification of end customer is not consistent
with associated account number. (formerly
CreditorConsistency).
Specification of creditor's address, which is
required for payment, is missing/not correct
(formerly IncorrectCreditorAddress).
Party who initiated the message is not
recognised by the end customer
End customer specified is not known at
associated Sort/National Bank Code or does no
longer exist in the books

Page 13 of 18

TXN

B2C

BE07

MissingDebtorAddress

Specification of debtor's address, which is


required for payment, is missing/not correct.

TXN

B2C

TXN

B2C

TXN

B2C

BE08
BE22
BE09

MissingDebtorName
MissingCreditorName
InvalidCountry

Debtor name is missing


Creditor name is missing
Country code is missing or Invalid

TXN

B2C

TXN

B2C

TXN

B2C

BE10
BE11
BE12

InvalidDebtorCountry
InvalidCreditorCountry
InvalidCountryOfResidence

Debtor country code is missing or Invalid


Creditor country code is missing or Invalid
Country code of residence is missing or Invalid Generic usage if cannot specifically
identify debtor or creditor

TXN

B2C

BE13

InvalidDebtorCountryOfResidence

TXN

B2C

BE14

InvalidCreditorCountryOfResidence

TXN

B2C

BE15

InvalidIdentificationCode

Country code of debtor's residence is missing


or Invalid
Country code of creditor's residence is missing
or Invalid
Identification code missing or invalid
Generic usage if cannot specifically
identify debtor or creditor

TXN

B2C

BE16

InvalidDebtorIdentificationCode

TXN

B2C

BE17

InvalidCreditorIdentificationCode

TXN

B2C

TXN

B2C

BE18
BE19

InvalidContactDetails
InvalidChargeBearerCode

TXN

B2C

BE20

InvalidNameLength

TXN

B2C

BE21

MissingName

TXN

B2C

CURR IncorrectCurrency

Currency of the payment is incorrect

CUST RequestedByCustomer
DS0A DataSignRequested
DS0B UnknownDataSignFormat

Cancellation requested by the Debtor


Data signature is required.
Data signature for the format is not available or
invalid.
The signer certificate is revoked.
The signer certificate is not valid (revoked or
not active).
The signer certificate is not present.
The authority of the signer certification sending
the certificate is unknown.
Signer is not allowed to sign this operation
type.
Signer is not allowed to sign for this account.

DS0C SignerCertificateRevoked
DS0D SignerCertificateNotValid
DS0E IncorrectSignerCertificate
DS0F SignerCertificationAuthoritySignerNotValid
DS0G NotAllowedPayment
DS0H NotAllowedAccount
DS0K NotAllowedNumberOfTransaction
DS10

Signer1CertificateRevoked

Generic usage if cannot specifically


identify debtor or creditor

Debtor or Ultimate Debtor identification code


missing or invalid
Creditor or Ultimate Creditor identification code
missing or invalid
Contact details missing or invalid
Charge bearer code for transaction type is
invalid
Name length exceeds local rules for payment
type.
Name missing or invalid
Generic usage if cannot specifically
identify debtor or creditor

The number of transaction is over the number


allowed for this signer.
The certificate is revoked for the first signer.

Page 14 of 18

DS11

Signer1CertificateNotValid

DS12

IncorrectSigner1Certificate

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

DS22

IncorrectSigner2Certificate

DS23

SignerCertificationAuthoritySigner2NotValid

The certificate is not valid (revoked or not


active) for the second signer.
The certificate is not present for the second
signer.
The authority of signer certification sending the
certificate is unknown for the second signer.

TXN

B2C

DT01

InvalidDate

Control

B2C

DT02

InvalidCreationDate

TXN

B2C

DT03

InvalidNonProcessingDate

TXN

B2C
B2C

DT04
DT05

FutureDateNotSupported

TXN

TXN

B2C

DT06

Control

B2C

ExecutionDateChanged
DUPL DuplicatePayment

Control

B2C

Control

B2C

Control

B2C

Control

B2C

Control

B2C

Control

B2C

Control

The certificate is not valid (revoked or not


active) for the first signer.
The certificate is not present for the first signer.

Invalid date (eg, wrong settlement date) or


missing
Invalid creation date and time in Group Header
(eg, historic date)
Invalid non bank processing date (eg, weekend
or local public holiday)
Future date not supported
Associated message, payment information
block or transaction was received after agreed
processing cut-off date, i.e., date in the past.

InvalidCutOffDate
Execution Date has been modified in order for
transaction to be processed
Payment is a duplicate of another payment

DU01
DU02
DU03
DU04
DU05
ED01
ED03

DuplicateMessageID
DuplicatePaymentInformationID
DuplicateTransaction
DuplicateEndToEndID
DuplicateInstructionID
CorrespondentBankNotPossible
BalanceInfoRequest

Message Identification is not unique.


Payment Information Block is not unique.
Transaction is not unique.
End To End ID is not unique.
Instruction ID is not unique.
Correspondent bank not possible.
Balance of payments complementary info is
requested
Settlement of the transaction has failed.
File Format incomplete or invalid
Syntax error reason is provided as narrative
information in the additional reason information.

B2C

ED05
FF01
FF02

SettlementFailed
Invalid File Format
SyntaxError

TXN

B2C

FF03

InvalidPaymentTypeInformation

TXN

B2C

TXN

B2C

FF04
FF05

InvalidServiceLevelCode
InvalidLocalInstrumentCode

Payment Type Information is missing or invalid Generica usage if cannot specify


Service Level or Local Instrument
code
Service Level code is missing or invalid
Local Instrument code is missing or invalid

TXN

B2C

FF06

InvalidCategoryPurposeCode

Category Purpose code is missing or invalid

Page 15 of 18

TXN

B2C

TXN

B2C

TXN

B2C

TXN

B2C

FF07
FF08
FF09
FF10

InvalidPurpose
InvalidEndToEndId
InvalidChequeNumber
BankSystemProcessingError

MD01 NoMandate
MD02 MissingMandatoryInformationIn Mandate
MD05 CollectionNotDue
MD06 RefundRequestByEndCustomer
MD07 EndCustomerDeceased
MS02 NotSpecifiedReasonCustomer Generated
MS03 NotSpecifiedReasonAgent

Generated

Purpose is missing or invalid


End to End Id missing or invalid
Cheque number missing or invalid
File or transaction cannot be processed due to
technical issues at the bank side
No Mandate
Mandate related information data required by
the scheme is missing.
Creditor or creditor's agent should not have
collected the direct debit
Return of funds requested by end customer
End customer is deceased.
Reason has not been specified by end
customer
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

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

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 InvalidDebtorClearingSystemMemberIdentifi Debtor ClearingSystemMember identifier is


er
invalid or missing

TXN

B2C

RC10 InvalidCreditorClearingSystemMemberIdentif Creditor ClearingSystemMember identifier is


ier
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

Transaction reference is not unique within the


message.

NotUniqueTransactionReference

Generic usage if cannot specify


between debit or credit account

Generic usage if cannot specify


between debit or credit account

Page 16 of 18

Generic usage if cannot specify


between debit or credit account

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.
Specification of the creditors name and/or
address needed for regulatory requirements is
insufficient or missing.
Regulatory Reason
Regulatory or Central Bank Reporting
information missing, incomplete or invalid.
Tax information missing, incomplete or invalid.

RR03 Missing Creditor Name or Address

TXN

B2C

RR04 Regulatory Reason


RR05 RegulatoryInformationInvalid

TXN

B2C

RR06 TaxInformationInvalid

TXN

B2C

RR07 RemittanceInformationInvalid

TXN

B2C

RR08 RemittanceInformationTruncated

TXN

B2C

RR09 InvalidStructuredCreditorReference

TXN

B2C

RR10 InvalidCharacterSet

TXN

B2C

RR11 InvalidDebtorAgentServiceID

TXN

B2C

RR12 InvalidPartyID

TXN

B2C

SL01

Specific Service offered by Debtor Agent

SL02

Specific Service offered by Creditor Agent

TM01 InvalidCutOffTime

Remittance information structure does not


comply with rules for payment type.
Remittance information truncated to comply
with rules for payment type.
Structured creditor reference invalid or missing.
Character set supplied not valid for the country
and payment type.
Invalid or missing identification of a bank
proprietary service.
Invalid or missing identification required within
a particular country or payment type.
Due to specific service offered by the Debtor
Agent
Due to specific service offered by the Creditor
Agent
Associated message, payment information
block or transaction was received after agreed
processing cut-off time.

Page 17 of 18

CHANGE CONTROL -- Customer Payment Status Report pain.002.001.03


Notation of recent change

REVISION
DATE

NOTES

XML TAG

CHANGE
REQUESTED BY

CHANGE
DOCUMENTED
BY

30-Oct-09 <InitgPty><Id><OrgId><BICOrBEI>

Inclusion for proper placement of BICorBEI for sender of message

CGI Oct-09 Mtg

SColles

30-Oct-09 <InitgPty><Id><OrgId><Othr><SchmeNm><Cd>
20-Nov-09

Changed note that Bank Id should not be BIC


Updated Overview contents and code values

CGI Oct-09 Mtg


CGI Oct-09 Mtg

30-Dec-09
30-Dec-09
30-Dec-09
30-Dec-09
28-Jul-10
11-May-11
21-Nov-12

Updated Rule to include ACTC


Updated Rule
Updated Rule
Updated Rule
Update of CGI Logo and 'Data Content Principle'

CGI Dec-09 Mtg


DDobbing
DDobbing
DDobbing
CGI Work Group

SColles
SColles
SColles
SColles
SColles
SColles
SColles

JPMChase

SColles

<OrgnlGrpInfAndSts><GrpSts>
<GrpHdr><InitgPty><OrgId><BICOrBEI>
<GrpHdr><InitgPty><OrgId><Othr><Id>
<OrgnlPmtInfAndSts><TxInfAndSts><OrgnlTxRef>

Approved by CGI Plenary


Removed Rows 174-176 which were duplicated entries

You might also like