NACHA ISO 20022 Guide For Camt.053 (Returns) Nov 2016 (1) 1

NACHA ISO 20022 Guide to
Mapping U.S. ACH Return

Items
November 2016
Version 1.0
Acknowledgements
This document was developed by Nasreen Quibria of Q INSIGHTS for NACHA-The Electronic
Payments Association. Thanks to the following financial institutions and other key stakeholders for
providing insights that were applied in the creation of one or more of the NACHA ISO 20022
Mapping Guides and Spreadsheets:
 ACI Worldwide
 Bank of America
 Bayer
 BBVA Compass
 BNY Mellon
 BOK Financial
 Bottomline Technologies
 Citi
 Commerzbank
 Deutsche Bank
 DNB
 Fifth Third Bank
 IBM
 JPMorgan Chase
 Microsoft
 PNC
 Oracle
 SAP
 US Bank
 Wells Fargo
2|Page
Table of Contents
1. Overview ................................................................................................................................ 5
2. Bank to Customer Statement (camt.053) File Structure and Content for Returns ....... 6
a. Parties of the Transaction .................................................................................................. 6
b. Scenario .............................................................................................................................. 7
c. camt.053 XML Payment Message File Structure ............................................................ 8
1) The Group Header ......................................................................................................... 9
2) Statement ....................................................................................................................... 9
a) Balance ....................................................................................................................... 9
b) Entry .............................................................................................................................. 9
d. U.S. ACH Payments .......................................................................................................... 10
e. Example of U.S. ACH to ISO 20022 camt.053 Reversal ............................................... 11
f. ISO 20022 File Format Table ............................................................................................ 15
1) The Group Header ....................................................................................................... 17
2) Statement ..................................................................................................................... 18
3) Entry ............................................................................................................................... 19
3. NACHA File Mapping Details ............................................................................................. 40
a. File Header Record – All Formats ................................................................................... 40
b. Company/Batch Header Record – All SECs Except IAT ............................................. 42
c. CCD & PPD Entry Detail Record..................................................................................... 44
d. CTX Entry Detail Record .................................................................................................. 46
e. CCD, PPD, or CTX Addenda Record ............................................................................ 48
f. Batch/Control Record – All Formats .............................................................................. 50
g. File Control Record – All Formats ................................................................................... 52
4. Return Reason Codes ......................................................................................................... 53
5. Appendix .............................................................................................................................. 62
a. The Character Set ............................................................................................................ 62
1) Basic Latin ..................................................................................................................... 62
2) Special Characters in XML Content .......................................................................... 63
b. ISO Country Codes .......................................................................................................... 64
3|Page
c. External Code List ............................................................................................................. 64
d. Related Resources ........................................................................................................... 64
1) ISO 20022 ....................................................................................................................... 64
2) Common Global Implementation – Market Practice (CGI-MP) ........................... 64
3) European Payments Council (EPC) Guidelines for SEPA Transactions ................. 65
6. Revision History..................................................................................................................... 66
4|Page
1. Overview
NACHA aims to provide guidance on the use of ISO 20022 applied to U.S. ACH formats. This
document describes and references NACHA’s recommended interpretations and guidelines
to follow when mapping NACHA return items to the ISO 20022 format. The status and
reconciliation of submitted payments against the original pain.001 credit transfer file and/or
pain.008 direct debit file that happen after settlement i.e., not reported earlier with pain.002,
will have a return reason in the Bank to Customer Statement (camt.053) message. For
rejected items that happen prior to settlement that is provided through the bank to
corporate Customer Payment Status Report (pain.002) please refer to the separate NACHA
Guide on pain.002.
Note that this document focuses on the details of the Bank to Customer Statement Report
for Returns ONLY and not intended to be a complete guide to bank account statements.
The version recommended by NACHA for use of these formats is camt.053.01.02 in alignment
with the Single Euro Payment Area (SEPA) implementation guideline put forth by the
European Payments Council (EPC) and the current and future trend in global adoptions of
ISO 20022 standards. With this, NACHA desires to maximize global interoperability for U.S.
based companies.
This document should be read alongside the NACHA camt.053 ISO 20022 Mapping
Spreadsheet, which offers the full set of data elements and sub elements in the camt.053
XML file. Knowledge of XML and NACHA rules and formats is recommended to interpret this
document.
© 2016 NACHA - The Electronic Payments Association. All rights reserved.
This guide is intended for educational purposes only and does not constitute legal advice. It may be
updated as the needs of the industry evolve. Users are encouraged to periodically ensure they have
the most current version.
5|Page
2. Bank to Customer Statement (camt.053) File Structure and Content
for Returns
a. Parties of the Transaction

The ISO concepts of different parties are described in the table below.
ISO 20022
Synonym Description
Participant
Party sending the payment information.

This may be the payer itself, an agent,
Initiating Party Originator
Service Bureau, or the parent company
shared service center
Party that owes an amount of money to
Ordering Party
Debtor the (ultimate) creditor and whose
Buyer
account is debited with the payment
Party that originally ordered goods or
services and to whom the seller has sent
Ultimate Debtor Ultimate Payer the invoice. Ultimate Debtor is used when
the receiver of the invoice is different
from the payer
Party to which an amount of money is
Creditor Seller due and whose account is credited with
the payment
Party which is the ultimate beneficiary of
the payment. For example, when
payment is made to an account of a
Ultimate Creditor Ultimate Payee
financing company, but the ultimate
beneficiary is the customer of the
financing company
Debtor Agent Payer’s Bank Party is the Bank of the Payer/Buyer
Creditor Agent Payee’s Bank Party is the Bank of the Payee/Seller
Financial institution that receives the

instruction from the initiating party and
Forwarding Agent Bank
forwards it to the next agent in the
payment chain for execution
6|Page
b. Scenario
The purpose of this section is to provide the entire chain of electronic information
exchange between the Debtor, the Debtor’s Agent, the Creditor’s Agent and the
Creditor. The high level process flow is illustrated below.
Figure 1: ISO 20022 Payment Process Flows
1. The Debtor (Originator) receives an invoice for a purchase that they made.
2. The Debtor creates the payment instruction, a Credit Transfer Initiation (pain.001) file
that is sent to the Financial Institution, the Debtor Agent (or ODFI).
3. The Debtor Agent validates the message and sends a Payment Status Report
(pain.002) notifying the Debtor if the file is accepted or rejected.
4. The information included in every single payment is validated against each payment
system and the Debtor Agent sends a Payment Status Report (pain.002) reporting
rejected payments to the Debtor, if any.
5. The Debtor Agent transmits a file via the clearing house to the Creditor Agent (or
RDFI) to process the payments. If any of the payments are rejected on execution
day, the Debtor Agent sends a Payment Status Report (pain.002) reporting rejected
payments to the Debtor. Otherwise the Debtor Agent will send a Debit Notification
report (camt.054) to the Debtor reporting executed payments.
6. The Creditor Agent sends a Credit Notification report (camt.054) to the Creditor
reporting incoming payments.
7. Debtor Agent and/or Creditor Agent sends an Interim Account Report (camt.052) to
the Debtor and/or Creditor.
8. Debtor Agent and/or Creditor Agent sends an Account Statement (camt.053) to the
Debtor and/or Creditor.
7|Page
Note that this document is limited to camt.053 message transactions related to return
items and does not address the other message types described above.
c. camt.053 XML Payment Message File Structure

A file must contain a single Document (Envelope), which has a single XML message.
The structure of the Bank to Customer Statement message is composed of two
building blocks: Group Header and Statement as illustrated in the following diagram.
Figure 2: camt.053 XML File Structure
8|Page
1) The Group Header
The Group Header is mandatory and must be present once. It contains general
elements that apply to the whole camt.053 message such as
MessageIdentification and CreationDateAndTime.
2) Statement
The Statement building block is mandatory and repetitive. It contains
components such as Balance and Entry.
a) Balance
Balance information is part of the Statement block, and can be present
more than once. Each statement will contain an opening and closing
balance for one or more accounts at a given point in time.
b) Entry
Each Entry is part of the Statement and can be repetitive. It contains
detailed transaction information on the entries booked to an account(s).
9|Page
d. U.S. ACH Payments
Today it is not possible to transmit ISO 20022 XML files through the U.S. clearing systems
(Operators). As such, U.S. financial institutions that receive NACHA formatted return
entry items must translate these to ISO 20022 XML-based files for corporate clients that
have adopted the standard.
Certain standard NACHA “formatting” fields (e.g., record type codes, record size,
etc.) highlighted in Part 3 of this document that are specific to U.S. ACH format are
not carried forward in the ISO 20022 messages. In migrating to ISO 20022 standards
we recommend corporations and financial institutions work closely together to test
and validate the ISO 20022 XML files to identify any potential issues in the handling of
items returned after settlement.
Figure 3: U.S. ACH Credit Entry Process Flow
10 | P a g e
e. Example of U.S. ACH to ISO 20022 camt.053 Reversal
Following submission of a payment instruction file a credit transaction has been reversed as illustrated below. Note that
some details of the record file are left out of this example.
1. Group Header XML Message

<?xml version="1.0" encoding="UTF-8"?>
XML Declaration <Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.053.001.02">
<BkToCstmrStmt>
<GrpHdr>
Unique reference created by bank <MsgId>99345678912</MsgId>
When camt.053 file was generated <CreDtTm>2016-12-12T11:35:01</CreDtTm>
<MsgRcpt>
<Id>
<OrgId>
<Othr>
Message Recipient ID <Id>GE45678</Id>
</Othr>
</OrgId>
</Id>
</MsgRcpt >
</GrpHdr>
11 | P a g e
2. Entry XML Message
<Ntry>
Credit due to a returned credit transfer
<CdtDbtInd>CRDT</CdtDbtInd>
<Sts>BOOK</Sts>
<ValDt>
<Dt>2016-12-10</Dt>
</ValDt>
<BkTxCd>
<Domn>
Payment <Cd>PMNT</Cd>
<Fmly>
Issued Credit Transfer
<Cd>ICDT</Cd>
Reversal due to payment return <SubFmlyCd>RRTN</ SubFmlyCd >
</Fmly>
</Domn>
</BkTxCd>
<NtryDtls>
<TxDtls>
<Refs>
Identification Number
<EndToEndId>20072840342</EndToEndId >
</Refs>
<AmtDtls>
<Amt>
Amount <InstdAmt Ccy=
“USD”>2065.00</InstdAmt>
</Amt>
</AmtDtls>
<RltdPties>
Company Name
<Dbtr>
<Nm>Global Enterprises</Nm>
<Id>
<OrgId>
<Othr>
12 | P a g e
Company Identification (10-digit ID assigned by <Id>987654321</Id>
the bank e.g., Tax ID) <SchmeNm>
<Cd>TXID</Cd>
</SchmeNm>
</Othr>
</OrgId>
</Id>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
Account Number
<Id>4854697999999</Id>
</Othr>
</Id>
</DbtrAcct>
<Cdtr>
Individual Name / Receiving Company Name <Nm>Jane Smith</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
Account Number <Id>22716534</Id>
</Othr>
</Id>
</CdtrAcct>
</RltdPties>
<RltdAgts>
<DbtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
Originating DFI Identification (originating routing </ClrSysId>
number assigned) <MmbId>061000010</MmbId>
13 | P a g e
</ClrSysMmbId>
<Nm>NOLA BANK</Nm>
</FinInstnId>
</DbtrAgt>
<CdtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
Receiver DFI Identification (routing number </ClrSysId>
where receiver maintains his account) <MmbId>061000010</MmbId>
</ClrSysMmbId>
<Nm>USA BANK</Nm>
</FinInstnId>
</CdtrAgt>
<RtrInf>
<Rsn>
Return Reason Code (e.g., Incorrect Account <Cd>AC01</Cd>
Number) </Rsn>
</RtrInf>
</TxDtls>
</NtryDtls>
</Ntry>
14 | P a g e
f. ISO 20022 File Format Table
The Bank to Customer Statement message is described in the following table and
shows how these blocks are to be coded within the actual XML file. Mandatory ISO
20022 fields and key data elements required to map the NACHA file formats to the
ISO 20022 XML message are highlighted. Please pay attention to the column "Maps to
NACHA Format Field" when implementing support for Bank to Customer Statement
messages for the U.S. market. Failure to provide files that meet the specifications
outlined may result in files and/or transactions being rejected.
Note that not all elements have been repeated in this document and should be
taken into account where applicable in bank specific criteria, and only relevant
return information have been highlighted.
The column headings used in the table are described below:
 ISO Index: index used in the official ISO 20022 XML Message Definition Report
(www.iso20022.org)
 ISO Field Name: name and abbreviation for a data element
 Tag Level: specifies the tag depth of the ISO field name within the document
represented by a ‘+’. For example:
‘+’ would represent a Parent Element
‘++’ would represent the Child Element of the previous Parent Element
+ <>
++ <>
<>
+++ <>
<>
<>
G DTH TAG STRUCTURE
Note that where optional tags that have not been populated, the tag should
be omitted from the file along with its parent tag. Also, “empty tag” implies a
choice component.
 Description: explanation for the message item
 Mult: is short for multiple, identifying the number of occurrences of an element
[1..1] = mandatory, only one occurrence
[1..n] = mandatory and repetitive
15 | P a g e
[0..1] = optional, only one occurrence
[0..n] = optional and repetitive
{Or ... Or} indicates a choice of elements
 Type: identifies data type and size
 M or O: specifies whether each tag and data element is mandatory or

optional
Mandatory Fields – fields must be populated or the batch will be rejected
Optional Fields – Originator to decide if this field needs to be populated
Entry Segment – Populate entry segment specifying the reason for the return
 Maps to NACHA Format Field: specifies whether each tag and data element
is applicable to NACHA return items.
 Mapping Guide: For a number of fields, please pay attention to the Usage
Rules that must be followed when implementing camt.053 bank to customer
statement files sent in the U.S. These are outlined throughout the document.
16 | P a g e
1) The Group Header
The Group Header contains information about the camt.053 message itself.
XML Declaration
Map from NACHA Format

ISO Field Name Content Description M/O Mapping Guide
Field
The XML header must follow the

<?xml version=”1.0” encoding=”utf-8”?> This tag must always be
recommendation from
<Document placed before the group M
http://www.iso20022.org beginning with the
xmlns=”urn:iso:std:iso:20022:tech:xsd:camt.053.001.02”> header tag
Declaration outlined
This tag must always be
Bank to Customer Statement <BkToCstmrStmt> placed before the group M
header tag
Group Header Block
ISO Map from NACHA Format

ISO Field Name Tag Level Content Description Mult Type M/O Mapping Guide
Index Field
Set of characteristics
shared by all individual
Group Header transactions included in
1.0 + [1..1] M
<GrpHdr> the message
Empty tag
The reference of the
bank/CSM initiating the
‘R’ message. Unique
identification, as
assigned by the initiating
Message
party, and sent to the Max35Text
1.1 Identification ++ [1..1] M Unique identifier assigned
next party in the chain
<MsgId>
to unambiguously
identify the message.
Note: This ID cannot be

reused on future files
17 | P a g e
Group Header Block

Index Field
Date and time that the

Creation Date Time file was created
1.2 ++ [1..1] ISODateTime M
<CreDtTm>
YYYY-MM-DDThh:mm:ss
2) Statement
The Statement segment first reports general statement information: the account which is reported on and balance
details for the relevant book date. It is also repeated for each currency on account.
Statement Block – This can occur multiple times

Index Field
Reports on booked
entries and balances for
Statement
2.0 + a cash account [1..n] M
<Stmt>
Empty tag
Date and time at which
Creation Date Time
2.4 ++ the message was [1..1] ISODateTime M
<CreDtTm>
created
Range of time between
Period for what statement
a start date and an end
is generated used to infer
date for which the
From To Date NACHA File Creation Date
2.5 ++ account statement is [0..1] M
<FrToDt> & File Creation Time
issued
(Record 1, Field 5) &
(Record 1, Field 6)
Empty tag
From Date Time Date and time at which
5.1.0 +++ [1..1] ISODateTime M
<FrDtTm> the range starts
To Date Time Date and time at which
5.1.1 +++ [1..1] ISODateTime M
<ToDtTm> the range ends
NOTE that this document highlights return information only and not intended to be a complete guide to bank account statements.
18 | P a g e
3) Entry
The Entry segment contains details of the transaction booked on the account.
Entry Segment – This can occur multiple times

Index Field
Set of elements used to
specify an entry in the
Entry
2.76 ++ report [0..n] O
<Ntry>
Empty tag
Entry Reference Unique reference for the Max35Text
2.77 +++ [0..1] O
<NtryRef> entry
Amount Amount of money in the Amount
2.78 +++ [1..1] M
<AmtCcy="AAA"> cash entry
Credit Debit Indicates whether the
Code CRDT - Credit
2.79 Indicator +++ entry is a credit or a [1..1] M
DBIT - Debit
<CdtDbtInd> debit entry
Value is TRUE or FALSE. Should only be
If CdtDbtInd is ’CRDT’ and
Indicates whether or not shown if TRUE.
Reversal Indicator Indicator RvslInd is ’true’ the original
2.80 +++ the entry is the result of a [0..1] O
<RvslInd> entry was a debit
reversal Usage Rule: This element should only be
present if the entry is the result of a reversal.
Status of an entry on the
Status Code
2.81 +++ books of the account [1..1] M Set value to “BOOK”
<Sts>
servicer
Date and time when an
entry is posted to an
Booking Date account on the account
2.82 +++ [0..1] O
<BookgDt> servicer's books
Empty tag
Date ISODate
4.1.0 ++++ Specified date [1..1] M
<Dt>
Date and time at which
assets become available
to the account owner in
case of a credit entry, or
Value Date
2.83 +++ cease to be available to [0..1] O
<ValDt>
the account owner in
case of a debit entry
Empty tag
19 | P a g e

Index Field
Date entry settled. For original Direct Debit
RequestedCollectionDate value from
For CCD, PPD and CTX,
pain.008
Date ISODate Batch Header Record,
4.1.0 ++++ Specified date [1..1] M
<Dt> Effective Entry Date
For original Credit Transaction
(Record 5, Field 9)
<RequestedExecutionDate> value from
pain.001
Unique reference as
Account Servicer assigned by the account
Max35Text
2.84 Reference +++ servicing institution to [0..1] O
<AcctSvcrRef> unambiguously identify
the entry
fully identify the type of
Bank Transaction
underlying transaction
2.91 Code +++ [1..1] M
resulting in an entry
<BkTxCd>
Empty tag
provide the domain, the
family and the sub-
family of the bank
Domain
2.92 ++++ transaction code, in a [0..1] O
<Domn>
structured and
hierarchical format
Empty tag
Specifies the business
Code Code
2.93 +++++ area of the underlying [1..1] M Set value to “PMNT” for Payments
<Cd>
transaction
Specifies the family and
the sub-family of the
bank transaction code,
Family within a specific domain,
2.94 +++++ [1..1] M
<Fmly> in a structured and
hierarchical format
Empty tag
1. For ALL, Batch Header
Refer to ISO Bank Transaction Code List
Record, Service Class
Code Specifies the family Code Code (Record 5, Field 2)
2.95 ++++++ [1..1] M Set value to "ICDT" for credit transfers
<Cd> within a domain 2. For ALL, Batch Control
(pain.001) or "IDDT" for direct debit
Record, Service Class
(pain.008)
Code (Record 8, Field 2)
20 | P a g e

Index Field
Specifies the sub-
Code
2.96 Sub Family Code ++++++ product family within a [1..1] M
Set value to "ATXN" for ACH Transactions or
specific family
"RRTN" for reversal due to return
Bank transaction code in
a proprietary form, as
Proprietary
2.97 ++++ defined by the issuer [0..1] O
<Prtry>
Empty tag
Proprietary bank
Code transaction code to Max35Text
2.98 +++++ [1..1] M
<Cd> identify the underlying
transaction
Identification of the
Issuer Max35Text
2.99 +++++ issuer of the proprietary [0..1] O
<Issr>
bank transaction code
Entry Details
provide details on the
Entry Details
2.135 +++ entry [1..n] M
<NtryDtls>
Empty tag
provide details on
Batch
2.136 ++++ batched transactions [0..1] O
<Btch>
Empty tag
Number Of Max15Nume
Number of individual
Transactions Number of credit/debit entries in the batch
2.139 +++++ transactions included in [0..1] ricText O
<NbOfTxs> entry
the batch
Total amount of money
Total Amount Amount
2.140 +++++ reported in the batch [0..1] O
<TtlAmtCcy="AAA">
entry
Credit Debit Indicates whether the
Code CRDT = Credit Indicate a Debit or Credit , if Total Amount
2.141 Indicator +++++ batch entry is a credit or [0..1] O
DBIT = Debit is provided
<CdtDbtInd> a debit entry
21 | P a g e

Index Field
Transaction Details
provide information on
Transaction Details the underlying
2.142 ++++ [0..n] O
<TxDtls> transaction(s)
Empty tag
provide the
References identification of the
2.143 +++++ [0..1] O
<Refs> underlying transaction
Empty tag
Point to point reference,
as assigned by the
Message
sending party, to Max35Text <MessageIdentification> from pain.001 or
2.144 Identification +++++ [0..1] O
unambiguously identify pain.008
<MsgId>
the batch of
transactions
Unique identification, as
Payment Information assigned by a sending <PaymentInformationIdentification> from
Identification party, to unambiguously Max35Text pain.001 or pain.008; or other reference
2.146 +++++ [0..1] O
<PmtInfId> identify the payment identifying the original payment instruction,
information group within if available
the message
assigned by an
Instruction
instructing party for an Max35Text <InstructionIdentification> from pain.001 or
2.147 Identification ++++++ [0..1] O
instructed party, to pain.008. Reported when available
<InstrId>
unambiguously identify
the instruction
assigned by the initiating
For CCD, PPD, or CTX,
party, to unambiguously
End To End Entry Detail Record, Identification Number as included in the
identify the transaction. Max35Text
2.148 Identification ++++++ [0..1] O Individual Identification original entry, <EndToEndIdentification>
This identification is
<EndToEndId> Number (Record 6 Field 7) from pain.001 or pain.008
passed on, unchanged,
throughout the entire
end-to-end chain
22 | P a g e

Index Field
Proprietary reference
related to the underlying
Proprietary
2.153 ++++++ transaction [0..1] O
<Prtry>
Empty tag
Type Identifies the type of Max35Text
2.154 +++++++ [1..1] M
<Tp> reference reported
Proprietary reference
Reference specification related to Max35Text
2.155 +++++++ [1..1] M
<Ref> the underlying
transaction
Set of elements
providing detailed
Amount Details information on the
2.156 +++++ [0..n] O
<AmtDtls> original amount
Empty tag
Identifies the amount of
money to be moved
between the debtor and
creditor, before
deduction of charges,
expressed in the
currency as ordered by
the initiating party and
Instructed Amount
2.1.0 ++++++ provides currency [0..1] O
<InstdAmt>
exchange information in
case the instructed
amount and/or currency
is/are different from the
entry amount and/or
currency.
Empty tag
Amount of money to be Original amount from pain.001 or pain.008
moved between the For CCD, PPD and CTX,
debtor and creditor, Entry Detail Record, e.g., <InstdAmt
Amount Amount
2.1.1 +++++++ before deduction of [1..1] M Amount (Record 6, Field Ccy="EUR">5000.00</InstdAmt>
<AmtCcy="AAA">
charges, expressed in 6)
the currency as ordered
by the initiating party
23 | P a g e

Index Field
Amount of the
Transaction Amount underlying transaction
2.1.9 ++++++ [1..1] M
<TxAmt>
Empty tag
Amount of money to be
moved between the
debtor and creditor,
Amount Amount
2.1.10 +++++++ before deduction of [1..1] M
<AmtCcy="AAA">
charges, expressed in
the currency as ordered
by the initiating party
Related Parties Information
identify the parties
Related Parties related to the underlying
2.199 +++++ [0..1] O
<RltdPties> transaction
Empty tag
Party that initiated the
payment that is reported
Initiating Party
2.200 ++++++ in the entry [0..1] O
<InitgPty>
Empty tag
Name by which a party Max140Text
Name is known and which is
9.1.0 +++++++ [0..1] O
<Nm> usually used to identify
that party
Unique and
unambiguous way of
identifying an
Identification
9.1.12 +++++++ organisation or an [0..1] O
<Id>
individual person
Empty tag
Unique and
Organisation unambiguous way to
9.1.13 +++++++
Identification identify an organization [1..1] M
{OR +
<OrgId>
Empty tag
24 | P a g e

Index Field
Code allocated to
organisations by the ISO
9362 Registration
Authority, under an
international
BIC Or BEI identification scheme, as Identifier Usage Rule: If <Othr> is populated,
9.1.14 +++++++
<BICOrBEI> described in the latest [0..1] O <BICOrBEI> should not be populated
++
version of the standard
ISO 9362
Banking (Banking
telecommunication
messages, Bank Identifier
Codes)
Unique identification of
an organization as
assigned by an
Other +++++++
9.1.15 institution, using an [0..n] O
<Othr> ++
identification scheme
Empty Tag
Identification +++++++ Identification assigned Max35Text
9.1.16 [1..1] M
<Id> +++ by an institution
Name of the
+++++++
9.1.17 Scheme Name identification scheme [0..1]
+++ O
<SchmeNm>
Empty tag
Also include when populating Identification
field.
Name of the
+++++++ identification scheme, in
9.1.18 Code [1..1] Code Examples:
++++ a coded form as M
{OR <Cd> “TXID” for Tax Identification Number
published in an external
“CUST” Customer Identification Number
list
or other Code from External Code List
+++++++ Name of the

9.1.19 Proprietary [1..1] Max35Text Usage Rule: If <Cd> is populated, <Prtry>
++++ identification scheme, in M
OR} <Prtry> should not be populated
a free text form
25 | P a g e

Index Field
Unique and
Private Identification +++++++ unambiguous
9.1.21 [1..1] Usage Rule: If <OrgId> is populated,
<PrvtId> + identification of a M
OR} <PrvtId> should not be populated
private person, e.g.,
passport
Debtor Information
Party that owes an
amount of money to the
Debtor
2.201 ++++++ (ultimate) creditor [0..1] O
<Dbtr>
Empty tag
1. For ALL, Immediate Origin 1 & 2* For original Credit Transactions
Name (Record 1, Field 12) (pain.001) map Company Name to Debtor
2. For CCD, PPD & CTX, Name
Batch Header Record,
Company Name (Record 3* & 4* For original Direct Debit (pain.008)
5, Field 3) map Individual/Receiving Company Name
Name by which a party
3. For CCD & PPD, Entry to Debtor Name
Name is known and which is Max140Text
9.1.0 +++++++ [0..1] O Detail Record,
<Nm> usually used to identify
Individual/Receiving *Note for 3rd party payment i.e., payment
that party
Company Name (Record made or received on behalf of, map to
6, Field 8) <UltimateDebtor><Name>
4. For CTX, Entry Detail
Record, Receiving
Company Name (Record
6, Field 9)
Unique and
unambiguous way of
identifying an
Identification
<Id>
individual person
Empty tag
Unique and
9.1.13 +++++++
{OR +
<OrgId>
Empty tag
26 | P a g e

Index Field
Code allocated to
9362 Registration
Authority, under an
international
9.1.14 +++++++
{OR ++
ISO 9362 Banking
(Banking
telecommunication
Codes)
an organization as
assigned by an
9.1.15 Other +++++++
institution, using an [0..n] O
OR} <Othr> ++
Empty Tag
1. For ALL, File Header
Record, Immediate Origin
(Record 1, Field 4)
2. For CCD, PPD & CTX,
Batch Header Record, For Original Credit Transactions (pain.001)
9.1.16 [1..1] M Company Identification map 10-digit ID assigned by the bank
(Record 5, Field 5)
3. For ALL, Batch Control
Record, Company
Identification (Record 8,
Field 7)
Name of the
+++++++
+++ O
<SchmeNm>
Empty tag
27 | P a g e

Index Field
field.
+++++++ Name of the
9.1.18 Code [1..1] Code
++++ identification scheme, in M Examples:
{OR <Cd>
a coded form as “TXID” for Tax Identification Number
+++++++ Name of the
a free text form
Unique and
passport
Debtor Account Information
Unambiguous
identification of the
account of the debtor
Debtor Account to which a debit entry
2.202 ++++++ [0..1] O
<DbtrAcct> will be made as a result
of the transaction
Empty tag
Unique and
unambiguous
Identification account between the
1.1.0 +++++++ [1..1] M
<Id> account owner and the
account servicer
Empty tag
International Bank
Account Number (IBAN)
- identifier used
1.1.1 IBAN +++++++ IBANIdentifier Usage Rule: If <Othr> is populated,
internationally by [1..1] M
{OR <IBAN> + <IBAN > should not be populated
financial institutions to
uniquely identify the
account of a customer
28 | P a g e

Index Field
an account, as assigned
by the account servicer,
1.1.2 Other +++++++
using an identification [1..1] M
OR} <Othr> +
scheme
Empty tag
Identification +++++++ Identification assigned Entry Detail Record, DFI For original Direct Debit (pain.008) map
1.1.3 [1..1] Max35Text M
<Id> ++ by an institution Account Number (Record Receiver’s Bank Account Number
6, Field 5)
Nature, or use, of the
Type account
1.1.8 +++++++ [0..1] O
<Tp>
Empty tag
Name of the Type in a For ALL, Entry Detail For original Direct Debit (pain.008) set
1.1.9 Code +++++++
coded form as published [1..1] Code M Record, Transaction Code value to "CACC" for checking and "SVGS"
(OR <Cd> +
in an external list (Record 6, Field 2) for savings
1.1.10 Proprietary +++++++ Specifies the Type as a Usage Rule: If <Cd> is populated, < Prtry>
[1..1] Max35Text M
OR} <Prtry> + proprietary code should not be populated
Creditor Information
Party to which the
Creditor amount of money is due
2.204 ++++++ [0..1] O
<Cdtr>
Empty tag
1. For ALL, Immediate
Origin Name (Record 1,
Field 12) 1 & 2* For original Direct Debit (pain.008)
2. For CCD, PPD & CTX, map Company Name to Creditor Name
Batch Header Record,
Company Name
(Record 5, Field 3) 3* & 4* For original Credit Transactions
Name
9.1.0 +++++++ Name of the Creditor [0..1] Max140Text O 3. For CCD & PPD, Entry (pain.001) map Individual/Receiving
<Nm>
Detail Record, Receiving Company Name to Creditor Name
Company Name
(Record 6, Field 8) *Note for 3rd party payment i.e., payment
4. For CTX, Entry Detail made or received on behalf of, map to
Record, Receiving <UltimateCreditor> <Name>
Company Name
(Record 6, Field 9)
29 | P a g e

Index Field
Unique and
unambiguous way of
identifying an
Identification
<Id>
individual person
Empty tag
Unique and
9.1.13 +++++++
{OR +
<OrgId>
Empty tag
Code allocated to
9362 Registration
Authority, under an
international
9.1.14 +++++++
++
ISO 9362 Banking
(Banking
telecommunication
Codes)
an organization as
assigned by an
Other +++++++
9.1.15 institution, using an [0..n] O
<Othr> ++
Empty Tag
Record, Immediate Origin
(Record 1, Field 4)
Batch Header Record, For original Direct Debit (pain.008) map 10-
9.1.16 [1..1] M Company Identification digit ID assigned by the bank
(Record 5, Field 5)
Record, Company
Field 7)
30 | P a g e

Index Field
Name of the
+++++++
+++ O
<SchmeNm>
Empty tag
Name of the field
+++++++ identification scheme, in
9.1.18 Code [1..1] Code
++++ a coded form as M Examples:
{OR <Cd>
published in an external “TXID” for Tax Identification Number
list “CUST” Customer Identification Number
+++++++ Name of the

a free text form
Unique and
passport
Creditor Account Information
Unambiguous
account of the creditor
to which a credit entry
Creditor Account
2.205 ++++++ will be posted as a result [0..1] O
<CdtrAcct>
of the payment
transaction
Empty tag
Unique and
unambiguous
Identification account between the
1.1.0 +++++++ [1..1] M
<Id> account owner and the
account servicer
Empty tag
31 | P a g e

Index Field
International Bank
Account Number (IBAN)
- identifier used
1.1.1 IBAN +++++++ IBANIdentifier Usage Rule: If <Othr> is populated,
internationally by [1..1] M
{OR <IBAN> + <IBAN > should not be populated
financial institutions to
uniquely identify the
account of a customer
an account, as assigned
by the account servicer,
1.1.2 Other +++++++
using an identification [1..1] M
OR} <Othr> +
scheme
Empty tag
Identification +++++++ Identification assigned Entry Detail Record, DFI For original Credit Transaction (pain.001)
1.1.3 [1..1] Max35Text M
<Id> ++ by an institution Account Number (Record map Receiver’s Bank Account Number
6, Field 5)
Nature, or use, of the
Type account
1.1.8 +++++++ [0..1] O
<Tp>
Empty tag
Name of the Type in a For ALL, Entry Detail
1.1.9 Code +++++++ For original Credit Transaction (pain.001)
coded form as published [1..1] Code M Record, Transaction Code
(OR <Cd> + map set value to "CACC" for checking and
in an external list (Record 6, Field 2)
"SVGS" for savings
1.1.10 Proprietary +++++++ Specifies the Type as a Usage Rule: If <Cd> is populated, < Prtry>
[1..1] Max35Text M
OR} <Prtry> + proprietary code should not be populated
Related Agents Information

identify the agents
Related Agents related to the underlying
2.211 +++++ [0..1] O
<RltdAgts> transaction
Empty tag
32 | P a g e

Index Field
Debtor Agent Information
Financial institution
servicing an account for
Debtor Agent
2.212 ++++++ the debtor [0..1] O
<DbtrAgt>
Empty tag
Unique and
unambiguous identifier
of a financial institution,
as assigned under an
Financial Institution
internationally
6.1.0 Identification +++++++ [1..1] M
recognised or
<FinInstnId>
proprietary identification
scheme
Empty tag
Bank Identifier Code.
Code allocated to
financial institutions by
the Registration
Authority, under an
international
Usage Rule: Either <BIC> or <ClrSysMmbId>
BIC +++++++ identification scheme, as BICIdentifier
6.1.1 [0..1] O must be populated
<BIC> + described in the latest
ISO 9362 Banking
(Banking
telecommunication
Codes)
Unique and
Clearing System of a clearing system
Member +++++++ member, as assigned by
6.1.2 [0..1] O
Identification + the system or system
<ClrSysMmbId> administrator.
Empty tag
33 | P a g e

Index Field
Specification of a pre-
agreed offering
between clearing
Clearing System agents or the channel
+++++++
6.1.3 Identification through which the [0..1] O
++
<ClrSysId> payment instruction is
processed
Empty tag
Specifies the Clearing
System Member
6.1.4 Code +++++++ If <MemberIdentification> is present, set to
Identification as [1..1] Code M
{OR <Cd> +++ “USABA”
local instrument code list
6.1.5 Proprietary +++++++ System Member Max35Text Usage Rule: If <Cd> is populated,
[1..1] M
OR} <Prtry> +++ Identification, as a <Prtry> should not be populated
proprietary code
Record, Immediate
Destination (Record 1,
Field 3)
2. For CCD, PPD and CTX,
Company Batch Header,
Originating DFI 1, 3, and 4 for original Credit Transaction
Identification (Record 5, (pain.001) maps to bank routing number
Field 12) where original file went
3. For ALL, Batch/Control
Record, Originating DFI 2 & 5 for original Direct Debit (pain.008)
Member
+++++++ Bank clearing code or Max35Text Identification (Record 8, maps to bank routing number of the
6.1.6 Identification [1..1] M
++ transit routing number Field 10) institution initiating the entry/where receiver
<MmbId>
4. For ALL, Entry Detail maintains his account
Record, Receiving DFI
Field 3) (i.e., ODFI of
original entry) and Check
Digit (Record 6, Field 4)
Addenda Record,
Original Receiving DFI
Field 6)
34 | P a g e

Index Field
For original Credit Transaction (pain.001)
For ALL, File Header
Identifies the bank may map to bank name of where original
Name +++++++ Record, Immediate
6.1.7 processing the [0..1] Max140Text O file went
<Nm> + Destination Name
transaction
(Record 1, Field 11)
Creditor Agent Information

Financial institution
servicing an account for
Creditor Agent
2.213 ++++++ the creditor [0..1] O
<CdtrAgt>
Empty tag
Unique and
of a financial institution,
as assigned under an
Financial Institution
internationally
6.1.0 Identification +++++++ [1..1] M
recognised or
<FinInstnId>
proprietary identification
scheme
Empty tag
Bank Identifier Code.
Code allocated to
financial institutions by
the Registration
Authority, under an
international
Usage Rule: Either <BIC> or <ClrSysMmbId>
BIC +++++++ identification scheme, as BICIdentifier
6.1.1 [0..1] O must be populated
<BIC> + described in the latest
ISO 9362 Banking
(Banking
telecommunication
Codes)
35 | P a g e

Index Field
Unique and
Clearing System of a clearing system
Member +++++++ member, as assigned by
6.1.2 [0..1] O
Identification + the system or system
<ClrSysMmbId> administrator.
Empty tag
Specification of a pre-
agreed offering
between clearing
Clearing System agents or the channel
+++++++
6.1.3 Identification through which the [0..1] O
++
<ClrSysId> payment instruction is
processed
Empty tag
System Member
6.1.4 Code +++++++ If <MemberIdentification> is present, set to
Identification as [1..1] Code M
{OR <Cd> +++ “USABA”
local instrument code list
6.1.5 Proprietary +++++++ System Member Max35Text Usage Rule: If <Cd> is populated,
[1..1] M
OR} <Prtry> +++ Identification, as a <Prtry> should not be populated
proprietary code
Record, Immediate
1 & 3 for original Direct Debit (pain.008)
Destination (Record 1,
maps to bank routing number where
Field 3)
original file went
Company Batch Header,
2, 4 & 5 for original Credit Transaction
Member Originating DFI
+++++++ Bank clearing code or Max35Text (pain.001) maps to bank routing number of
6.1.6 Identification [1..1] M Identification (Record 5,
++ transit routing number the institution initiating the entry/where
<MmbId> Field 12) (i.e., RDFI of the
receiver maintains his account
original entry)
Record, Originating DFI
Field 10)
Continued
36 | P a g e

Index Field
4. For ALL, Entry Detail
Record, Receiving DFI
1, 3 & 4 for original Direct Debit (pain.008)
maps to bank routing number where
Field 3) (i.e., ODFI of the
original file went
Member original entry) and
+++++++ Bank clearing code or Max35Text
6.1.6 Identification [1..1] M Check Digit (Record 6,
++ transit routing number 2, 4 & 5 for original Credit Transaction
<MmbId> Field 4)
(pain.001) maps to bank routing number of
5. For ALL, Original
the institution initiating the entry/where
Receiving DFI
receiver maintains his account
Field 6)
For ALL, File Header
Identifies the bank For original Direct Debit (pain.008) may
Name Record, Immediate
6.1.7 ++++++ processing the [0..1] Max140Text O map to bank name of where original file
<Nm> Destination Name
transaction went
(Record 1, Field 11)
Underlying reason for the
Purpose payment transaction
2.224 +++++ [0..1] O
<Purp>
Empty tag
Underlying reason for the
2.225 Code payment transaction, as
++++++ [1..1] Code M
{OR <Cd> published in an external
purpose code list
2.226 Proprietary Purpose, in a proprietary

++++++ [1..1] Max35Text M
OR} <Prtry> form
Return Information
provide the return
Return Information
2.293 +++++ information [0..1] O
<RtrInf>
Empty tag
Bank transaction code
Original Bank included in the original
2.294 Transaction Code ++++++ entry for the transaction [0..1] O
<OrgnlBkTxCd>
Empty tag
37 | P a g e

Index Field
provide the domain, the
family and the sub-
family of the bank
Domain
2.295 +++++++ transaction code, in a [0..1] O
<Domn>
structured and
hierarchical format
Empty tag
Specifies the business
Code +++++++
2.296 area of the underlying [1..1] Code M
<Cd> +
transaction
Specifies the family and
the sub-family of the
bank transaction code,
Family +++++++ within a specific domain,
2.297 [1..1] M
<Fmly> + in a structured and
hierarchical format
Empty tag
Code +++++++ Specifies the family

2.298 1..1] Code M
<Cd> ++ within a domain
Specifies the sub-

Sub Family Code +++++++
2.299 product family within a [1..1] Code M
<SubFmlyCd> ++
specific family
Proprietary bank
transaction code to
Proprietary +++++++ identify the underlying
2.300 [0..1] O
<Prtry> + transaction
Empty tag
Bank transaction code in

Code +++++++
2.301 a proprietary form, as [0..1] Max35Text O
<Cd> +
defined by the issuer
Identification of the
Issuer +++++++
2.302 issuer of the proprietary [0..1] Max35Text O
<Issr> +
bank transaction code
38 | P a g e

Index Field
Reason Information
Specifies the reason for
Reason the status report
2.304 ++++++ [0..1] O
<Rsn>
Empty tag
For CCD, PPD, CTX, Refer to "NACHA Return Reason Codes"
Reason for the status, as Addenda Record, Return and associated ISO External Code List. If a
2.305 Code
+++++++ published in an external [1..1] Code M Reason Code (Record 7, bank's status code is supported other than
{OR <Cd>
reason code list Field 3) a code from the External Code List, use
<AdditionalInformation> field
2.306 Proprietary Reason for the return, in

+++++++ [1..1] Max35Text M
OR} <Prtry> a proprietary form

Addenda Record, Date
of Death (Record 7, Field
Additional
Further details on the 5)
2.307 Information ++++++ [0..n] Max105Text O
status reason 2. For CCD, PPD & CTX,
<AddtlInf>
Addenda Record,
Addenda Information
(Record 7, Field 7)
39 | P a g e
3. NACHA File Mapping Details
The tables that follow summarize the NACHA file format mappings of relevant camt.053 fields. Note that for Return Entries each
field remains unchanged from the original entry, unless otherwise indicated.
a. File Header Record – All Formats
NACHA File Format Length Position M,R,O Content Description ISO 20022 Mapping Comments
File Header Record (1) - ALL
Code identifying the File Header Record is

1 Record Type Code 1 01-01 M Not mapped
"1"
2 Priority Code 2 02-03 R Currently only '01' is used Not mapped
For original Credit Transaction (pain.001) maps to
<EntryDetails><TransactionDetails><RelatedAgents>
<DebtorAgent><FinancialInstitutionIdentification>
<ClearingSystemMemberIdentification><MemberIdentification>
Bank transit routing number preceded by a For original Direct Debit (pain.008) maps to
3 Immediate Destination 10 04-13 M
blank space <EntryDetails><TransactionDetails><RelatedAgents>
<CreditorAgent><FinancialInstitutionIdentification>
Note also set <ClearingSystemMemberIdentifciation><Code> to

"USABA"
<EntryDetails><TransactionDetails><RelatedParties><Debtor>
<Identification><OrganisationIdentification><Other>
<Identification>
For original Direct Debit (pain.008) maps to

10-digit company number assigned by
<EntryDetails><TransactionDetails><RelatedParties><Creditor>
4 Immediate Origin 10 14-23 M bank typically 9-digit tax ID preceded by
<Identification><OrganisationIdentification><Other>
"1"
<Identification>
Also set when populating Identification field. Examples:

“TXID” for Tax Identification Number
40 | P a g e
The date the original file was created or
5 File Creation Date 6 24-29 M Not mapped. Infer from <Statement><FromToDate>
transmitted
Time of day the original file was created or

6 File Creation Time 4 30-33 O Not mapped. Infer from <Statement><FromToDate>
transmitted
Code to distinguish among multiple input

7 File ID Modifier 1 34-34 M files sent on the same day. Label the first "A" Not mapped2
(or "0") and continue in sequence
8 Record Size 3 35-37 M Number of bytes per record, always "94" Not mapped
9 Blocking Factor 2 38-39 M Number of records per block Not mapped
10 Format Code 1 40-40 M Must contain "1" Not mapped
<DebtorAgent><FinancialInstitutionIdentification><Name>
Immediate Destination Identifies the bank where the original file
11 23 41-63 O
Name went
<CreditorAgent><FinancialInstitutionIdentification><Name>
<Name>
Company's name or third-party vendor as
12 Immediate Origin Name 23 64-86 O
included in the original file
<Name>
May be blanks or space used for internal
13 Reference Code 8 87-94 O Not mapped*2
accounting purposes
NOTE:
*Field typically not used by U.S. banks
2 Usage may also vary with field populated based on bank specific criteria
41 | P a g e
b. Company/Batch Header Record – All SECs Except IAT
Company/Batch Header Record (5)
Code identifying the Batch Header

Record is "5"
Identifies the type of entries "200” = mixed
2 Service Class Code 3 02-04 M debits and credits “220” = credits Set <Entry><BankTransactionCode><Domain><Family><Code>
only“225” = debits only value to "ICDT" for credit transfers (pain.001) or "IDDT" for direct
debit (pain.008)
<Name>4
Originating company name that has the
3 Company Name 16 05-20 M
relationship with the receiver
<Name>5
Company Discretionary
4 20 21-40 O May be used for company's internal use Not mapped*
Data
<Identification><OrganizationIdentification><Other>
<Identification>

5 Company Identification 10 41-50 M 10-digit ID assigned by the bank
<Identification>

Not mapped
Set <Entry><BankTransactionCode><Domain><Code> value to

Field defines the type of ACH entries
6 Standard Entry Class Code 3 51-53 M "PMNT" for Payments
contained in the batch
Note, also set
<Entry><BankTransactionCode><Domain><Family>
<SubFamilyCode> value to "ATXN" for ACH Transactions or
"RRTN" for reversal due to return
42 | P a g e
Field contains the entry description from
the original Batch ID e.g., "PAYROLL",
71 Company Entry Description 10 54-63 M "TRADEPAY", "GAS BILL", etc. It may Not mapped
contain the identification of the ACH
Operator converting the entry
Descriptive date included in the original
8 Company Descriptive Date 6 64-69 O Not mapped
batch, if any
Map to <Entry><ValueDate><Date>
For original Direct Debit <RequestedCollectionDate> value from

9 Effective Entry Date 6 70-75 R The date this batch of ACH entries settled pain.008
For original Credit Transaction <RequestedExecutionDate> value

from pain.001
Inserted
The ACH Operator populates the actual
10 Settlement Date (Julian) 3 76-78 by ACH Not mapped
settlement date
Operator
Changed to reflect the Originator Status
Code of the financial institution initiating
111 Originator Status Code 1 79-79 M Not mapped
the Return Entry (i.e., the RDFI of the
original entry)
Changed to reflect the Routing Number
of the financial institution initiating the
121 Originating DFI Identification 8 80-87 M
Return Entry (i.e., the RDFI of the original
entry)
<DebtorAgent><FinancialInstitutionIdentification><ClearingSyste
mMemberIdentification><MemberIdentification>
Changed to the batch number assigned
131 Batch Number 7 88-94 M by the financial institution initiating the Not mapped
Return Entry
NOTE:
* Field typically not used by U.S. banks
1 For Return Entries, each field remains unchanged from the original entry, unless otherwise indicated
4 For 3rd party payment i.e., payment on behalf of, maps to <UltimateDebtor> fields
5 For 3rd party payment i.e., ultimate beneficiary of payment, maps to <UltimateCreditor> fields
43 | P a g e
c. CCD & PPD Entry Detail Record
CCD Length Position M,R,O Content Description ISO 20022 Mapping Comments
First Entry Detail Record (6)

Code identifying the Entry Detail Record is
"6"
<EntryDetails><TransactionDetails><RelatedParties>
<CreditorAccount><Type><Code>
Two-digit code that identifies checking and
savings account credits/debits or prenotes. For original Direct Debit (pain.008) maps to
21 Transaction Code 2 02-03 M
Changed to the appropriate Return Entry <EntryDetails><TransactionDetails><RelatedParties>
Transaction Code <DebtorAccount><Type><Code>
"CACC" = Current Account

"SVGS" = Savings Account
<ClearingSystemMemberIdentification>
<MemberIdentification>
First 8 digits of the receiver's bank transit
routing number. Changed to the Routing
31 Receiving DFI Identification 8 04-11 M Number of the institution receiving the
Return Entry (i.e., the ODFI of the original
Entry)
Note also set <ClearingSystemMemberIdentifciation><Code>

to "USABA"
Last digit of the receiver's transit bank <ClearingSystemMemberIdentification>
routing number. Changed to the Check <MemberIdentification>
41 Check Digit 1 12-12 M Digit calculated according to NACHA
standards and based on the Routing For original Direct Debit (pain.008) maps to
Number contained in positions 04-11 <EntryDetails><TransactionDetails><RelatedAgents>
<EntryDetails><TransactionDetails><RelatedParties><CreditorA
Transaction receiver's bank account
5 DFI Account Number 17 13-29 R ccount> <Identification><Other><Identification>
number
44 | P a g e
<DebtorAccount><Identification><Other><Identification>
Maps to
6 Amount 10 30-39 M The dollar amount of the item originated <EntryDetails><TransactionDetails><AmountDetails><Instructed
Amount> e.g., <InstdAmt Ccy="USD">5000.00</InstdAmt>
Identification Number field may be used by
the Originator to insert its own number for
tracing purposes. For CIE and MTE entries,
positions 40-54 are used for a 15-character
Individual Identification Individual Name, and positions 55-76 are
Number / Identification used for a 22-character Individual Maps to <EntryDetails><TransactionDetails><References>
71 15 40-54 O
Number / Check Serial Identification Number. For POP return <EndToEndIdentification>
Number entries, this field (positions 40-54) contains
the Check Serial Number (positions 40-48),
the Terminal City (positions 49-52) and the
Terminal State (positions 53-54) from the
original Entry
Name of Receiver. For CIE and MTE entries, <EntryDetails><TransactionDetails><RelatedParties>
positions 40-54 are used for a 15-character <Creditor><Name>5
Individual Name /
81 22 55-76 R Individual Name, and positions 55-76 are
Receiving Company Name
used for a 22-character Individual For original Direct Debit (pain.008) maps to
Identification Number <EntryDetails><TransactionDetails><RelatedParties>
<Debtor><Name>4
Field defined by the ODFI some banks
Discretionary Data / request it be left blank. For SHR and POS
Payment Type Code / return entries, this field (positions 77-78) is
91 2 77-78 R/M Not mapped*2
Card Transaction Type mandatory and contains the Card
Code Transaction Type Code (positions 77-78) of
the original Entry
"0" = no addenda record supplied, "1" =
10 Addenda Record Indicator 1 79-79 M Not mapped
one or more addenda records supplied
Means for the originator to identify the
individual entries. Field is constructed as
follows: the first 8 digits are the ODFI transit
routing number or Field 12 of the
111 Trace Number 15 80-94 M Company/Batch Header. The remainder Not mapped
positions must be a unique number in
sequential order. Changed to the Trace
Number assigned by the institution
preparing the Automated Return Entry
NOTE:
45 | P a g e
d. CTX Entry Detail Record
CTX Length Position M,R,O Content Description ISO 20022 Mapping Comments
First Entry Detail Record (6)

Code identifying the Entry Detail Record is
"6"
<CreditorAccount><Type><Code>
Two-digit code that identifies checking
and savings account cedits/debits or For original Direct Debit (pain.008) maps to
21 Transaction Code 2 02-03 M
prenotes. Changed to the appropriate <EntryDetails><TransactionDetails><RelatedParties>
Return Entry Transaction Code <DebtorAccount><Type><Code>
"CACC" = Current Account

"SVGS" = Savings Account
First 8 digits of the receiver's bank transit
routing number. Changed to the Routing
31 Receiving DFI Identification 8 04-11 M Number of the institution receiving the
Return Entry (i.e., the ODFI of the original
Entry)

"USABA"
Last digit of the receiver's transit bank
routing number. Changed to the Check
41 Check Digit 1 12-12 M Digit calculated according to NACHA
standards and based on the Routing
Number contained in positions 04-11

"USABA"
The receiver's bank account number. If For original Credit Transaction (pain.001) maps to
the account number exceeds 17 <EntryDetails><TransactionDetails><RelatedParties>
5 DFI Account Number 17 13-29 R positions, only use the left most 17 <CreditorAccount> <Identification><Other><Identification>
characters with spaces omitted and field
left justified For original Direct Debit (pain.008) maps to
46 | P a g e
<DebtorAccount> <Identification><Other><Identification>
Maps to <EntryDetails><TransactionDetails><AmountDetails>
The amount of the transaction in dollars
6 Total Amount 10 30-39 M <InstructedAmount>
with two decimal places
e.g., <InstdAmt Ccy="USD">5000.00</InstdAmt>
Identifying (e.g., accounting) number by
Maps to <EntryDetails><TransactionDetails><References>
7 Identification Number 15 40-54 O which the receiver is known to the
<EndToEndIdentification>
originator for descriptive purposes
The number of addenda records
associated with the CTX Entry Detail
Number of Addenda
8 4 55-58 M Record. Changed to the Trace Number Not mapped
Records
assinged by the institution preparing the
Automated Return Entry
<EntryDetails><TransactionDetails><RelatedParties><Creditor><
Name>5
Receiving Company
9 16 59-74 R Name of Receiver
Name/Individual Name
<EntryDetails><TransactionDetails><RelatedParties><Debtor><N
ame>4
10 Reserved 2 75-76 N/A Leave blank Not mapped*
Field defined by the ODFI some banks
11 Discretionary Data 2 77-78 R Not mapped*2
request it be left blank
"0" = no addenda record supplied, "1" =
12 Addenda Record Indicator 1 79-79 M Not mapped
one or more addenda records supplied
Means for the originator to identify the
individual entries. Field is constructed as
follows: the first 8 digits are the ODFI transit
routing number or Field 12 of the
131 Trace Number 15 80-94 M Company/Batch Header. The remainder Not mapped
positions must be a unique number in
sequential order. Changed to the Trace
Number assigned by the institution
preparing the Automated Return Entry
NOTE:
47 | P a g e
e. CCD, PPD, or CTX Addenda Record
CCD, PPD, or CTX Length Position M,R,O Content Description ISO 20022 Mapping Comments
Addenda Record (7) – CCD, PPD, or CTX
Code identifying the Addenda Record

type is "7"
2 Addenda Type Code 2 02-03 M Code identifying the Addenda type is "99" Not mapped
May map to
<EntryDetails><TransactionDetails><ReturnInformation>
<Reason><Code>
This field contains a standard code by an
Use <Code> values from ExternalStatusReasonCode List. Refer
3 Return Reason Code 3 04-06 M ACH Operator or RDFI to describe the
to "NACHA Return Reason Codes" tab associated with ISO
reason for returning an Entry
Code List. If a bank's status code is supported other than a
code from the External Code List, bank's status code is
supported other than a code from the External Code List, use
<AdditionalInformation> field
This field contains the Trace Number as
originally included on the forward Entry or
Prenotification. The RDFI must include the
Original Entry Trace Number in the
Addenda Record of an Entry being
41 Original Entry Trace Number 15 07-21 M returned to an ODFI, in the Addenda Not mapped
Record of an NOC, within an
Acknowledgement Entry, or with an RDFI
request for a copy of an authorization.
Copy data from positions 80-94 of the Entry
Detail Record
The date of death is to be supplied on
May map to
Entries being returned for reason of death
51 Date of Death 6 22-27 O <EntryDetails><TransactionDetails><ReturnInformation>
(return reason codes R14 and R15). To be
<AdditionalInformation>
used only with Return Code R14 or R15
This field contains the Receiving DFI
Identification as originally included on the
forward Entry or Prenotification that the
RDFI is returning or correcting. This field must
Original Receiving DFI be included in the Addenda Record for an
61 8 28-35 R
Identification Entry being returned to an ODFI, or within
the Addenda Record accompanying a
Notification of Change. Copy data from
positions 04-11 of the original Entry Detail
Record
48 | P a g e
to "USABA"
The Addenda Information field of a Return
Entry is used by the RDFI to relay
May map to
explanatory information that is required
7 Addenda Information 44 36-79 O <EntryDetails><TransactionDetails><ReturnInformation>
with the use of Return Reason Codes "R11"
<AdditionalInformation>
(Check Truncation Return) and "R17" file
Record Edit Criteria)
8 Trace Number 15 80-94 M Leave blank

Not mapped
NOTE:
49 | P a g e
f. Batch/Control Record – All Formats
Batch Control Record (8)

Code identifying the Company / Batch
Header Record is "8"
Identifies the type of entries in the batch
"200” = mixed debits and credits
2 Service Class Code 3 02-04 M Set <Entry><BankTransactionCode><Domain><Family><Code>
“220” = credits only
value to "ICDT" for credit transfers (pain.001) or "IDDT" for direct
“225” = debits only
debit (pain.008)
Total number of Entry Detail Records plus
addenda records (Record Types "6" and
3 Entry/Addenda Count 6 05-10 M Not mapped2
"7") in the batch. Requires 6 positions, right-
justify, left zero-fill.
Sum of 8-character Transit Routing/ABA
4 Entry Hash 10 11-20 M numbers in the batch (field 3 of the Entry Not mapped2
Detail Record)
Total Debit Entry Dollar
5 12 21-32 M Dollar total of debit entries in the batch Not mapped2
Amount in Batch
Total Credit Entry Dollar
6 12 33-44 M Dollar total of credit entries in the batch Not mapped2
Amount in Batch
<Identification>

7 Company Identification 10 45-54 R 10-digit ID assigned by the bank
<Identification>

Message Authentication
8 19 55-73 O Leave blank Not mapped*
Code
9 Reserved 6 74-79 N/A Leave blank Not mapped*2
Originating DFI Originating DFI ABA or transit routing <EntryDetails><TransactionDetails><RelatedAgents>
10 8 80-87 M
Identification number assigned <DebtorAgent><FinancialInstitutionIdentification>
50 | P a g e


to "USABA"
Sequential number assigned by the
11 Batch Number 7 88-94 M originator. Must be equal to Field 13 of the Not mapped
Company/Batch Header Record
NOTE:
51 | P a g e
g. File Control Record – All Formats
File Control Record (9)
Code identifying the File Control Record is

1 Record Type Code 1 01-01 M
"9" Not mapped
Value must be equal to the number of
2 Batch Count 6 02-07 M
batch header '5' records in the file Not mapped2
Number of physical blocks in the file,
3 Block Count 6 08-13 M including the file header and file control
records Not mapped
Sum of all '6' records and also '7' records, if
4 Entry/Addenda Count 8 14-21 M
used Not mapped2
Sum of all RDFI IDs in each '6' Record. If the
5 Entry Hash 10 22-31 M sum is more than 10 positions, truncate
leftmost numbers Not mapped2
Total Debit Entry Dollar
6 12 32-43 M Dollar total of debit entries in the file
Amount in File Not mapped2
Total Credit Entry Dollar
7 12 44-55 M Dollar total of credit entries in the file
Amount in File Not mapped2
8 Reserved 39 56-94 N/A Leave blank Not mapped*
NOTE:
52 | P a g e
4. Return Reason Codes
Originators may receive the following reason codes as part of the camt.053.001.02 message to detail the reason for the return that may
be applicable to credit transfer or direct debit transactions. The code is populated in the Code tag for Reason as outlined in the earlier
ISO 20022 File Format Table section 3 of this document.
Below are the NACHA Return Codes and associated ISO Status Reason Codes for returns and reversals from the External Code List.
Note that NACHA Dishonored Returns (R61-R70) are invalid entries for camt.053 transactions as they must be sent in a NACHA file
format to the ACH Network. Additionally Contested Dishonored Returns (R71-R77) and returns associated with Standard Entry Class
(SEC) Codes other than CCD, PPD and CTX are not currently supported and/or have not been mapped as highlighted below.
Table 1: Mapping of NACHA Return Codes to ISO ExternalStatusReason1 Codes
NACHA SEC ISO

NACHA Name Description ISO Name Description
Code Codes Code
Available and/or cash reserve balance
Amount of funds available to cover specified message
R01 Insufficient funds is not sufficient to cover the dollar ALL AM04 Insufficient Funds
amount is insufficient.
value of the debit Entry.
A previously active account has been
Closed Account Account number specified has been closed on the
R02 Account Closed closed by action of the customer or the ALL AC04
Number bank of account's books.
RDFI.
Account number structure is valid and
it passes the check digit validation, but ALL,
No Account / the account number does not EXCEPT
Inconsistent with End Identification of end customer is not consistent with
R03 Unable to Locate correspond to the individual identified ARC, BE01
Customer associated account number
Account in the Entry, or the account number BOC,
designated is not an existing account POP
i.e., not an open account.
Invalid Account Incorrect Account
R04 Account number structure is not valid. ALL AC01 Format of the account number specified is not correct
Number Structure Number
Unauthorized Debit
CCD or CTX debit Entry was transmitted
to Consumer
to a Consumer Account of the CCD, Transaction Not Transaction type not supported/authorized on this type
R05 Account Using AG03
Receiver and was not authorized by CTX Supported of account
Corporate SEC
the Receiver.
Code
ODFI has requested that the RDFI return
Returned per ODFI's an Erroneous Entry, or a credit Entry Reason is provided as narrative information in the
R06 ALL NARR* Narrative
Request originated without the authorization of additional reason information.
the Originator.
53 | P a g e
SEC ISO
NACHA NACHA Name Description ISO Name Description
Codes Code
Code
ALL
CONSU
MER
Authorization RDFI's customer (the Receiver) revoked SEC,
Unsuccessful Direct Debtor account cannot be debited for a generic
R07 Revoked by the authorization previously provided to EXCEPT AG07
Debit reason.
Customer the Originator for this debit Entry. ARC,
BOC,
POP,
RCK
The Receiver has placed a stop
R08 Payment Stopped payment order on this debit Entry e.g., ALL DS02 Order Cancelled An authorized user has cancelled the order.
recurring debit.
A sufficient book or ledger balance
exists to satisfy the dollar value of the
Amount of funds available to cover specified message
R09 Uncollected Funds transaction (i.e., uncollected checks), ALL AM07 Blocked Amount
amount is insufficient.
but the available balance is below the
dollar value of the debit entry.
Customer Advises RDFI has been notified by the Receiver ALL
Not Authorized, that the Entry is unauthorized, improper, EXCEPT Transaction forbidden on this type of account (formerly
R10 AG01* Transaction Forbidden
Improper, or ineligible, or part of an incomplete CCD, no Agreement)
Ineligible transaction. CTX
Used when returning a Check USE IF
truncation Entry. NO
Check Truncation [RDFI must use Addenda Record to OTHER
R111
Entry Return specify reason for the return e.g., CODE
"exceeds dollar amount", "stale date," APPLICA
etc.] BLE
A financial institution received an Entry
Account Sold to Reason is provided as narrative information in the
R12 to an account that was sold to another ALL NARR* Narrative
Another DFI additional reason information.
financial institution.
Entry contains a Receiving DFI Invalid Clearing ClearingSystemMemberidentifier is invalid or missing.
Invalid ACH
R13 Identification or Gateway Identification ALL RC08 System Member Generic usage if cannot specify between debit or
Routing Number
that is not a valid ACH routing number. Identifier credit account
Representative
Representative payee is either
Payee Deceased
deceased or unable to continue in that Reason is provided as narrative information in the
R14 or Unable to ALL NARR* Narrative
capacity. The beneficiary is not additional reason information.
Continue in That
deceased.
Capacity
54 | P a g e
SEC ISO
NACHA NACHA Name Description ISO Name Description
Codes Code
Code
Beneficiary or
Account Holder
(1) The beneficiary is deceased, or (2) End Customer
R15 (Other Than a ALL MD07 End customer is deceased.
The account holder is deceased. Deceased
Representative
Payee) Deceased
(1) Access to the account is restricted
Account Frozen / due to specific action taken by the
Account specified is blocked, prohibiting posting of
R16 Entry Returned Per RDFI or by legal action; or (2) OFAC has ALL AC06 Blocked Account
transactions against it.
OFAC Instruction instructed the RDFI or Gateway to
return the Entry.
Field(s) cannot be processed by RDFI.
[If the Entry cannot be processed by
File Record Edit Syntax error reason is provided as narrative information
R17 the RDFI, the field(s) causing the error ALL FF02* Syntax Error
Criteria in the additional reason information.
must be identified in the Addenda
Information field of the Return.]
(1) The effective Entry date for a credit
Entry is more than two Banking Days
after the Banking Day of processing as
Improper Effective
R18 established by the Originating ACH ALL DT01 Invalid date Invalid date (e.g., wrong or missing settlement date).
Entry Date
Operator; or (2) The Effective Entry
Date for a debit Entry is more than one
Banking Day after the processing date.
(1) Amount field is non-numeric.
(2) Amount field is not zero in a
Prenotification, DNE, ENR, Notification
of Change, refused Notification of
Change, or zero dollar CCD, CTX, or IAT
Entry.
(3) Amount field is zero in Entry other
R19 Amount Field Error ALL AM12 Invalid Amount Amount is invalid or missing.
than a Prenotification, DNE, ENR,
Notification of Change, Return,
Dishonored Return, contested
Dishonored Return, or zero dollar CCD,
CTX, or IAT Entry.
(4) Amount field is greater than $25,000
for ARC, BOC, POP Entries.
ACH Entry to a non-Transaction
Non-Transaction Account i.e., an account against Transaction forbidden on this type of account (formerly
R20 ALL AG01* Transaction Forbidden
Account which transactions are prohibited or no Agreement)
limited.
The Identification Number used in the
Invalid Company
R211 Company Identification Field is not CIE
Identification
valid.
55 | P a g e
NACHA SEC ISO
Code Codes Code
The Receiver has indicated to the RDFI Missing Debtor Specification of the debtor’s account or unique
Invalid Individual ID
R22 that the number with which the ALL RR01 Account or identification needed for reasons of regulatory
Number
Originator was identified is not correct. Identification requirements is insufficient or missing
Credit Entry
Any credit Entry that is refused by the Reason is provided as narrative information in the
R23 Refused by ALL NARR* Narrative
Receiver may be returned by the RDFI. additional reason information.
Receiver
The RDFI has received what appears
to be a duplicate Entry i.e., the trace
R24 Duplicate Entry number, date, dollar amount and/or ALL AM05 Duplication Duplication.
other data matches another
transaction.
Addenda record value indicator is
incorrect.
Addenda Type Code is invalid, out of
Remittance Remittance information structure does not comply with
R25 Addenda Error sequence, or missing. RR07
Information Invalid rules for payment type.
Number of Addenda Records exceeds
allowable maximum.
Addenda Sequence Number is invalid.
Mandatory Field Erroneous data or missing data in a Syntax error reason is provided as narrative information
R26 ALL FF02* Syntax Error
Error mandatory field. in the additional reason information.
(1) Original Entry Trace Number is not
present in the Addenda Record on a
Return or Notification of Change Entry;
or Syntax error reason is provided as narrative information
R27 Trace Number Error ALL FF02* Syntax Error
(2) Trace Number of an Addenda in the additional reason information.
Record is not the same as the Trace
Number of the preceding Entry Detail
Record.
Routing Number The Check digit for a routing number is Invalid Cheque
R28 ALL FF09 Cheque number missing or invalid.
Check Digit Error not valid. Number
The RDFI has been notified by the
Corporate
Receiver (non-consumer) that a CCD & Transaction forbidden on this type of account (formerly
R29 Customer Advises AG01* Transaction Forbidden
specific Entry has not been authorized CTX no Agreement)
Not Authorized
by the Receiver.
RDFI Not
Participant in RDFI does not participate in a Check Reason is provided as narrative information in the
R301 ALL NARR* Narrative
Check Truncation truncation program. additional reason information.
Program
56 | P a g e
NACHA SEC ISO
Code Codes Code
Permissible Return
RDFI may return a CCD or CTX Entry CCD & Reason is provided as narrative information in the
R31 Entry (CCD and NARR* Narrative
that the ODFI agrees to accept. CTX additional reason information.
CTX) only
RDFI Non-
R32 RDFI is not able to settle the Entry. ALL ED05* Settlement Failed Settlement of the transaction has failed.
Settlement
This Return Reason Code may only be
R331 Return of XCK Entry used to return XCK Entries and is at he XCK
RDFI's sole discretion.
RDFI's participation has been limited by
Limited Reason is provided as narrative information in the
R34 a federal or state advisor e.g., bank ALL NARR* Narrative
Participation DFI additional reason information.
closure.
Debit Entries (with the exception of ALL,
Return of Improper Creditor or creditor's agent should not have collected
R35 Reversing Entries) are not permitted for EXCEPT MD05 Collection Not Due
Debit Entry the direct debit. (Refund/Reversal)
CIE Entries or to loan accounts. CIE
ALL,
EXCEPT
ACH Entries (with the exception of ARC,
Return of Improper Reversing Entries) are not permitted for BOC, Reason is provided as narrative information in the
R36 NARR* Narrative
Credit Entry use with ARC, BOC, POP, RCK, TEL, WEB, POP, additional reason information.
and XCK. RCK, TEL,
WEB, &
XCK
Source Document The source document to which an ARC,
R371 Presented for ARC, BOC, or POP Entry relates has BOC,
Payment been presented for payment. POP
RDFI determines a stop payment order
Stop Payment on has been placed on the source ARC,
R381
Source Document document to which the ARC or BOC BOC
Entry relates.
RDFI determines that:
(1) the source document used for an
Improper Source ARC, BOC, or POP Entry to its Receiver's
Document / Source account is improper, or ARC,
R391 Document (2) an ARC, BOC, or POP Entry and the BOC,
Presented for source document to which the Entry POP
Payment relates have been presented for
payment and posted to the Receiver's
account.
Return ENR Entry by This Return Reason Code may only be
Federal used to return ENR Entries and is at the
R401 ENR
Government Federal Government Agency's sole
Agency discretion.
57 | P a g e
NACHA SEC ISO
Code Codes Code
Either the Transaction Code included in
Field 3 of the Addenda Record does
not conform to the ACH Record Format
Invalid Transaction Specifications contained in Appendix
R411 ENR
Code Three (ACH Record Format
Specifications) or it is not appropriate
with respect to an Automated
Enrollment Entry.
The Routing Number and the Check
Digit included in Field 3 of the
Routing Number /
R421 Addenda Record is either not a valid ENR
Check Digit Error
number or it does not conform to the
Modulus 10 formula.
The Receiver's account number
Invalid DFI Account included in Field 3 of the Addenda
R431 ENR
Number must include at least one alphameric
character.
The Individual ID Number /
Invalid Individual ID Identification Number provided in Field
Number / 3 of the Addenda Record does not
R441 ENR
Identification match a corresponding ID number in
Number the Federal Government Agency's
records.
The name of the consumer or
company provided in Field 3 of the
Invalid Individual Addenda Record either does not
R451 Name / Company match a corresponding name in the ENR
Name Federal Government Agency's records
or fails to include at least one
alphameric character.
The Representative Payee Indicator
Invalid Code included in Field 3 of the
R461 Representative Addenda Record has been omitted or ENR
Payee Indicator it is not consistent with the Federal
Government Agency's records.
The Entry is duplicate of an Automated
Duplicate
R471 Enrollment Entry previously initiated by ENR
Enrollment
a DFI.
58 | P a g e
NACHA SEC ISO
Code Codes Code
(1) The RDFI is located in a state that
has not adopted Revised Article 4 of
the Uniform Commercial Code (1990
Official Text) and has not revised its
customer agreements to allow for
State Law Affecting
R501 Electronic presentment; or RCK
RCK Acceptance
(2) The RDFI is located within a state
that requires all canceled Checks to a
specific type of account to be
returned to the Receiver within the
periodic statement.
Item related to RCK
Entry is Ineligible for A RCK Entry considered to be ineligible
R511 RCK
RCK Entry is or improper.
Improper
Stop Payment on A stop payment order has been
R521 Item Related to placed on the item to which the RCK RCK
RCK Entry Entry relates.
Item and RCK Entry In addition to an RCK Entry, the item to
R531 Presented for which the RCK Entry relates has also RCK
Payment been presented for payment.
NOT APPLICABLE - Codes used by ODFI for Dishonored Return Entries. Must be transmitted to ACH Network in NACHA File Format
The financial institution preparing the
Return Entry (the RDFI of the original ALL,
R612 Misrouted Return Entry) has placed the incorrect Routing EXCEPT
Number in the Receiving DFI IAT
Identification field.
The Originator's / ODFI's use of the
ALL,
Return of Erroneous reversal process has resulted in, or
R622 EXCEPT
or Reversing Debit failed to correct, an unintended credit
IAT
to the Receiver.
ALL,
The ODFI has received more than one
R672 Duplicate Return EXCEPT
Return for the same Entry.
IAT
59 | P a g e
NACHA SEC ISO
Code Codes Code
The Return Entry has not been sent ALL,
R682 Untimely Return within the time frame established by EXCEPT
these Rules. IAT
ALL,
One or more of the field requirements
R692 Field Error(s) EXCEPT
are incorrect.
IAT
The ODFI has received a Return Entry
Permissible Return
identified by the RDFI as being returned
Entry Not ALL,
with the permission of, or at the request
R702 Accepted / Return EXCEPT
of, the ODFI, but the ODFI has not
Not Requested by IAT
agreed to accept the Entry or has not
ODFI
requested the return of the Entry.
The financial institution preparing the
dishonored Return Entry (the ODFI of ALL,
Misrouted
R711 the original Entry) has placed the EXCEPT
Dishonored Return
incorrect Routing Number in the IAT
Receiving DFI Identification field.
The dishonored Return Entry has not ALL,
Untimely
R721 been sent within the designated time EXCEPT
Dishonored Return
frame. IAT
The RDFI is certifying that the original ALL,
Timely Original
R731 Return Entry was sent within the EXCEPT
Return
timeframe designated in these Rules. IAT
The RDFI is correcting a previous Return
Entry that was dishonored using Return ALL,
R741 Corrected Return Reason Code R69 (Field Error(s)) EXCEPT
because it contained incomplete or IAT
incorrect information.
The Return Entry was not a duplicate of ALL,
Return Not a
R751 an Entry previously returned by the EXCEPT
Duplicate
RDFI. IAT
The original Return Entry did not ALL,
R761 No Errors Found contain the errors indicated by the EXCEPT
ODFI in the dishonored Return Entry. IAT
The RDFI returned both the Erroneous
Non-Acceptance Entry and the related Reversing Entry, ALL,
R771 of R62 Dishonored or the funds relating to the R62 EXCEPT
Return dishonored Return are not recoverable IAT
from the Receiver.
60 | P a g e
NACHA ISO
NACHA Name Description SEC Codes ISO Name Description
Code Code
The IAT Entry is being returned due to
one or more of the following
conditions: ▪ Invalid DFI / Bank Branch
Country Code
▪ Invalid DFI / Bank Identification
IAT Entry Coding OUTBOUND Invalid Bank Bank Operation code specified in the message is not
R80 Number Qualifier AG02
Error IAT Operation Code valid for receiver.
▪ Invalid Foreign Exchange Indicator
▪ Invalid ISO Originating Currency Code
▪ Invalid ISO Destination Currency Code
▪ Invalid ISO Destination Country Code
▪ Invalid Transaction Type Code
The IAT Entry is being returned because
the Gateway does not have an End customer specified is not known at associated
Non-Participant in OUTBOUND Unknown End
R81 agreement with either the ODFI or the BE06 Sort/National Bank Code or does no longer exist in the
IAT Program IAT Customer
Gateway's customer to transmit books
Outbound IAT Entries.
Invalid Foreign The reference used to identify the Bank identifier is invalid or missing.
OUTBOUND
R82 Receiving DFI Foreign Receiving DFI of an Outbound RC02 Invalid Bank Identifier Generic usage if cannot specify between debit or
IAT
Identification IAT Entry is invalid. credit account.
The IAT Entry is being returned due to
Foreign Receiving OUTBOUND
R83 settlement problems in the foreign ED05* Settlement Failed Settlement of the transaction has failed.
DFI Unable to Settle IAT
payment system.
For Outbound IAT Entries, the Entry has
not been processed and is being
Entry Not Processed returned at the Gateway's discretion OUTBOUND
R84 RR04 Regulatory Reason Regulatory reason.
by Gateway because the processing of such Entry IAT
may expose the Gateway to excessive
risk.
The RDFI/Gateway has identified the
Entry as an Outbound internal payment
Incorrectly Coded
and is returning the Entry because it
Outbound ALL, EXCEPT Syntax error reason is provided as narrative information
R85 bears an SEC Code that lacks FF02* Syntax Error
International IAT in the additional reason information.
information required by the Gateway
Payment
for OFAC Compliance.
[For Gateway use only.]
NOTE:
*ISO Code mapped to multiple NACHA Codes
1Entries currently are not supported/mapped
2 Invalid entries for camt.053 transactions that must be sent in NACHA file format for ACH Network
61 | P a g e
5. Appendix
a. The Character Set

An increasing need for international data exchange led to a standardized
universal character set coding: Unicode. In XML messages, the Unicode
character set, encoded in UTF-8 (8-bit Universal Character Set Transformation
Format) is the official ISO 20022 character set. The camt.053.001.02 message
format supports characters restricted to the Basic Latin character set. Note that if
non supported characters are used in these fields they may lead to a rejection of
files or transactions in the payment chain.
Exceptionally, the content of Identifiers/reference data elements

 Must not start or end with a ‘/’
 Must not contain two consecutive ‘/’s anywhere in the data element
1) Basic Latin
The Basic Latin Unicode block is the first block of the Unicode standard. The
following are valid Basic Latin characters:
Character Description
a-z 26 small characters of the Latin alphabet
A–Z 26 capital characters of the Latin alphabet
0-9 10 numeric characters
/ solidus (slash)
- hyphen
? question mark
; Colon
( open parenthesis
) close parenthesis
. full stop
, comma
‘ apostrophe
+ plus
space
= equal to
! exclamation mark
“ quotation mark
% percent
& ampersand
* asterisk
< less than
> greater than
; semi-colon
@ at
62 | P a g e
Character Description
# pound (hash)
$ dollar
{ open curly bracket
} close curly bracket
[ left square bracket
] right square bracket
\ back slash
_ underscore
^ circumflex
` grave accent
| vertical line
~ tilde
Control Codes Description (in common use)
CR carriage return
LF line feed
2) Special Characters in XML Content

Certain characters, referred to as special characters, are used by the XML
structure and cannot be included within the data content itself. Use of these
characters will cause a validation error even when opening the file. Wherever
these special characters appear in the data, alternate character sets, known
as XML representation, must be substituted for them before the data may be
included in the XML file to be exported. The special characters and
corresponding XML representation are listed below.
Special Characters XML Representation

“ (double quote) &quote;
‘ (single quote) '
< (left brace) <
> (right brace) >
As an example, AB & C Transport would populate their name in a camt.053

message as:
<Cdtr>
<Nm>AB & C TRANSPORT </Nm
</Cdtr>
This method for handling special characters applies irrespective of whether

the full Unicode character set, or only the restricted Basic Latin character set,
is used.
63 | P a g e
b. ISO Country Codes
Code to identify a country, a dependency, or geopolitical interest on the basis of
country names obtained from the United Nations. The ISO country code list is
available on the Online Browsing Platform (OBP) website:
https://www.iso.org/obp/ui/#search
c. External Code List

ISO publishes a list of codes allowed within ISO 20022 XML message schemas.
Please see the inventory of External Code Lists on the ISO website:
http://www.iso20022.org/external_code_list.page
d. Related Resources
1) ISO 20022
The XML format of the camt.053 file is based on an XML standard published by
the ISO organization. ISO 20022 defines the formats for files used in the
financial area. The ISO 20022 Message Definition report (MDR), Message
Guideline (MUG), and XML schema camt.053.001.02.xsd can be downloaded
from the ISO20022 web site at
https://www.iso20022.org/message_archive.page
2) Common Global Implementation – Market Practice (CGI-MP)

The Common Global Implementation - Market Practice (CGI-MP) initiative
provides 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 other related activities, in the
payments domain.
The goal of CGI-MP is to simplify implementation for corporate users and,

thereby, to promote wider acceptance of ISO 20022 as the common XML
standard used between corporates and banks.
The mission of the CGI group will be 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.
Additional information on the CGI-MP can be here:

http://corporates.swift.com/en/cgi-mission-and-scope
64 | P a g e
3) European Payments Council (EPC) Guidelines for SEPA Transactions
Message Implementation Guidelines for SEPA ISO 20022 XML message
standards can be downloaded from the EPC website:
http://www.europeanpaymentscouncil.eu/index.cfm/sepa-direct-debit/iso-
20022-message-standards/
65 | P a g e
6. Revision History
Version Date Summary of Changes

1.0 November 2016 Creation Date
66 | P a g e

NACHA ISO 20022 Guide For Camt.053 (Returns) Nov 2016 (1) 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

NACHA ISO 20022 Guide For Camt.053 (Returns) Nov 2016 (1) 1

Transféré par

Droits d'auteur :

Formats disponibles

NACHA ISO 20022 Guide to

Mapping U.S. ACH Return

© 2016 NACHA - The Electronic Payments Association. All rights reserved.

a. Parties of the Transaction

Party sending the payment information.

Debtor Agent Payer’s Bank Party is the Bank of the Payer/Buyer

Creditor Agent Payee’s Bank Party is the Bank of the Payee/Seller

Financial institution that receives the

Figure 1: ISO 20022 Payment Process Flows

c. camt.053 XML Payment Message File Structure

Figure 2: camt.053 XML File Structure

Figure 3: U.S. ACH Credit Entry Process Flow

1. Group Header XML Message

The column headings used in the table are described below:

 ISO Field Name: name and abbreviation for a data element

‘+’ would represent a Parent Element

 Description: explanation for the message item

 Mult: is short for multiple, identifying the number of occurrences of an element

[1..1] = mandatory, only one occurrence

[1..n] = mandatory and repetitive

[0..n] = optional and repetitive

{Or ... Or} indicates a choice of elements

 Type: identifies data type and size

 M or O: specifies whether each tag and data element is mandatory or

Mandatory Fields – fields must be populated or the batch will be rejected

Optional Fields – Originator to decide if this field needs to be populated

Map from NACHA Format

The XML header must follow the

Group Header Block

ISO Map from NACHA Format

Note: This ID cannot be

ISO Map from NACHA Format

Date and time that the

Statement Block – This can occur multiple times

ISO Map from NACHA Format

Entry Segment – This can occur multiple times

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

+++++++ Name of the

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

+++++++ Name of the

ISO Map from NACHA Format

Related Agents Information

ISO Map from NACHA Format

ISO Map from NACHA Format

ISO Map from NACHA Format

Creditor Agent Information

ISO Map from NACHA Format

ISO Map from NACHA Format

2.226 Proprietary Purpose, in a proprietary

ISO Map from NACHA Format

Code +++++++ Specifies the family

Specifies the sub-