Pain, Ach, CTX and Nacha

NACHA ISO 20022 Credit
Transaction Guide to
Mapping U.S. ACH File
Formats – CCD, CTX, PPD and
Outbound IAT
November 2016
Version 3.0
Acknowledgements
This document was developed and updated 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. Payment Initiation (pain.001) Credit Transfer File Structure and Content ..................... 6
a. Parties of the Transaction ................................................................................................. 6
b. Scenario .............................................................................................................................. 7
c. pain.001 XML Payment Message File Structure ............................................................. 8
1) The Group Header ......................................................................................................... 9
2) Payment Information..................................................................................................... 9
3) Credit Transfer Transaction Information ...................................................................... 9
a) Remittance Information ............................................................................................ 9
d. U.S. ACH Payments .......................................................................................................... 10
e. Examples of U.S. ACH Payments ................................................................................... 11
f. ISO File Format Table ....................................................................................................... 17
1) The Group Header ....................................................................................................... 19
2) Payment Information................................................................................................... 22
3) Credit Transfer Transaction Information .................................................................... 33
3. NACHA File Mapping Details ............................................................................................. 62
a. File Header Record – All Formats................................................................................... 62
b. Company/Batch Header Record – All SECs Except IAT ............................................ 64
c. Company/Batch Header Record – IAT Only (Outbound Payments) ...................... 66
d. CCD or PPD Entry Detail Record ................................................................................... 69
e. CTX Entry Detail Record .................................................................................................. 71
f. IAT Entry Detail Record (Outbound Payments) ........................................................... 73
g. CCD Addenda Record (Optional) ............................................................................... 75
h. CTX Addenda Record (Optional) ................................................................................. 76
i. IAT First Addenda Record (710) (Outbound Payments) ............................................ 77
j. IAT Second Addenda Record (711) (Outbound Payments) ..................................... 79
k. IAT Third Addenda Record (712) (Outbound Payments) .......................................... 80
l. IAT Fourth Addenda Record (713) (Outbound Payments)........................................ 81
m. IAT Fifth Addenda Record (714) (Outbound Payments) ........................................ 82
3|Page
n. IAT Sixth Addenda Record (715) (Outbound Payments) ........................................... 83
o. IAT Seventh Addenda Record (716) (Outbound Payments) .................................... 84
p. IAT Addenda Record for Remittance Information (717) (Optional) (Outbound
Payments) ................................................................................................................................ 85
q. IAT Addenda Record for Foreign Correspondent Bank Information (718)
(Outbound Payments) ........................................................................................................... 86
r. Batch/Control Record – All Formats ............................................................................. 88
s. File Control Record – All Formats ................................................................................... 90
4. Remittance Information ..................................................................................................... 91
a. CCD Addenda – NACHA Endorsed Banking Conventions for TXP, DED, and TPP
Payments ................................................................................................................................. 91
1) Unstructured ................................................................................................................. 92
2) Structured...................................................................................................................... 93
b. CTX Addenda .................................................................................................................. 98
1) Structured Data – STP 820 (EDI) .................................................................................. 99
2) Comparison of ISO 20022 XML Syntax with STP 820 ............................................... 101
3) DED .............................................................................................................................. 103
c. IAT Addenda .................................................................................................................. 103
5. Same Day ACH .................................................................................................................. 104
6. Exceptions – Returns and Rejects ................................................................................... 105
7. Appendix ............................................................................................................................ 106
a. The Character Set ......................................................................................................... 106
1) Basic Latin ................................................................................................................... 106
2) Special Characters in XML Content ........................................................................ 107
b. ISO Country Codes ........................................................................................................ 108
c. External Code List .......................................................................................................... 108
d. Related Resources......................................................................................................... 108
1) ISO 20022 ..................................................................................................................... 108
2) Common Global Implementation – Market Practice (CGI-MP) ......................... 108
3) European Payments Council (EPC) Guidelines for SEPA Transactions ............... 109
8. Revision History................................................................................................................... 110
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 the ISO 20022 payment initiation message to U.S. ACH Standard
Entry Class Codes: CCD, CTX, PPD, and Outbound IAT.
The format of the file to be used to submit Payment Instructions is part of the Payment
Initiation (PAIN) suite. For credit transactions, the specific format is called pain.001. The
version recommended by NACHA for use of these formats is pain.001.001.03 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 pain.001 ISO 20022 Mapping
Spreadsheet, which offers the full set of data elements and sub elements in the pain.001 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. Payment Initiation (pain.001) Credit Transfer File Structure and
Content
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, or
Initiating Party Originator
the parent company shared service
center
Party which received the Invoice (when
Invoicee Originator that party is different from the Debtor or
Ultimate Debtor)
Party that owes an amount of money to
Originator
Debtor the (ultimate) creditor and whose
Ordering Party / 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
Message Recipient Receiver / Beneficiary Receiver of the payment message
The party that issued the invoice (when
Invoicer Receiver / Beneficiary that party is different from the Creditor or
Ultimate Creditor)
Party to which an amount of money is
Creditor Receiver / Beneficiary 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 Beneficiary
financing company, but the ultimate
beneficiary is the customer of the
financing company
Bank (Originating Bank,
Debtor agent Originator’s Bank, Payer’s Party is the Bank of the Payer
Bank)
Bank (Beneficiary’s Bank,
Creditor agent Party is the Bank of the Beneficiary
Seller’s Bank)
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
Interbank Clearing and Settlement
pacs messages
Debtor Agent / ODFI* Creditor Agent / RDFI*

pain.002 camt.05x pain.002 camt.05x
Customer Credit Transfer
Customer Direct Debit

Customer Payment
Customer Payment
Account Reporting
Account Reporting
Status Report
Status Report
pain.001 pain.008
Purchase
Invoice
Debtor / Originator* Creditor / Receiver*
*NOTE: RDFI / ODFI and Originator / Receiver are reversed when pain.008 is originated
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. Once a file is transmitted via the clearing house to the Creditor Agent (or RDFI), 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 pain.001 message transactions and does not
address pain.002 or the camt messages described above.
c. pain.001 XML Payment Message File Structure

A file must contain a single Document (Envelope), which has a single XML message.
The structure of the Payment Initiation message is composed of three building blocks:
Group Header, Payment Information, and Credit Transfer Transaction Information
illustrated in the following diagram.
Figure 2: pain.001 XML File Structure
Group Header (1..1)
Payment Information (1..n)
Credit Transfer
Transaction
Information (1..n)
Remittance
Information (0..1)
The message may contain several Payment Information parts to which one or several
Credit Transfer Transaction Information parts are included.
8|Page
1) The Group Header
The Group Header is mandatory and must be present once. It is the set of
characteristics shared by all individual transactions included in the message, and
used to identify the file. It contains the common identifying elements: Message
Identification, Creation Date and Time, Authorisation, Number of Transactions,
Control Sum, Initiating Party, and Forwarding Agent.
2) Payment Information
The Payment Information is mandatory and can be present more than once. It
provides the set of details of the message between the (ultimate) debtor and the
(ultimate) creditor. It also represents a logical grouping of payments. The
information can include such elements as Debtor, Debtor Account, Payment
Type Information, Payment Method, and Requested Execution Date for the
transactions contained in the block.
3) Credit Transfer Transaction Information

Credit Transfer Transaction Information is part of the Payment Information, is
mandatory, and can be repetitive. It represents the actual payments to be made
and contains information related to the credit side of the transaction, such as
Creditor (Receiver), Creditor Agent (Receiver’s Bank) and Remittance
Information.
a) Remittance Information
The optional Remittance Information can be repetitive when used to

provide additional structured or unstructured remittance information to
support the bundling of invoices and credit notes to one payment.
It should be noted that this Guide offers documentation for remittance

information, including the future support of CCD addenda. Given that
state agencies today do not accept XML data, NACHA does not support
the transmission of XML messages for CCD+ or other SEC Codes at this
time. However, this information has been included in preparation for when
markets evolve.
Please refer to the Remittance section (Part 4) of this document for more
detailed information on how to handle remittance information for the
different SEC Codes.
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 ISO 20022 XML-based files
must translate these to NACHA file formats. The financial institutions that translate the
ISO 20022 payment instruction files feed into an existing process flow. It is general
practice for the banks to populate standard “formatting” fields (e.g., record type
codes, record size, etc. highlighted in Part 3 of this document) based on the NACHA
Operating Rules. All customer-specific information is populated from the XML file or
Setup process. Otherwise, the fields are being populated during the creation of the
NACHA file by the ODFI system (e.g., Entry Hash, Entry/Addenda Count) based on
accepted transactions.
It is important to be aware of possible overpopulation in an XML message and to

send more information than that may be relevant. We recommend corporations and
financial institutions work closely together to test and validate the ISO 20022 XML files
as well as determine how to handle potential extraneous information.
Figure 3: U.S. ACH Credit Entry Process Flow
Translate Interbank Clearing and Settlement

from ISO
20022 to
CCD
NACHA file NACHA File Formats CTX
formats
Debtor Agent / ODFI* IAT Creditor Agent / RDFI*
Customer Credit Transfer
pain.001
Purchase
Invoice
Debtor / Originator Creditor / Receiver

Flow of information Flow of funds
As multiple payment types such as wires, ACH, and checks may be transmitted within
a credit transfer payment instruction (pain.001) file, for U.S. ACH payments, it is
important to take note of the guidance outlined in the following.
10 | P a g e
e. Examples of U.S. ACH Payments
Example 1: File Header Record “1”
Immediate Origin (10-digit company number assigned by bank e.g., Tax ID): 1234567891
File Creation Date: February 14, 2015
File Creation Time: 11:35
Immediate Origin Name (Originator): ABC Company
Figure 4: NACHA File Format
1 2 3 4 5 6 7 8 9
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234
Example Data
101 987654321123456789115021411351094101USA BANK ABC Company
XML File Format
The 10-digit U.S. company number assigned by the financial institution may be further defined by including the
identification of the scheme name such as Tax ID or Employer Identification Number. However, this is not required.
Note that other details of the record file are left out of this example.
11 | P a g e
Group Header XML Message
<?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">
<CstmrCdtTrfInitn>
<GrpHdr>
<CreDtTm>2015-02-14T11:35:01</CreDtTm>
File Creation Date + File Creation Time
<InitgPty>
<Nm>ABC Company</Nm>
Immediate Origin Name
<Id>
<OrgId>
<Othr>
<Id>1234567891</Id>
Immediate Origin
<SchmeNm>
<Cd>TXID</Cd>
</SchmeNm>
</Othr>
</OrgId>
</Id>
</InitgPty>
</GrpHdr>
Example 2: Company / Batch Header Record “5”
Company Name: ABHC CLM PMT CR

Company Identification (10-digit company number assigned by bank): 1234567891
Originating DFI Identification (Originating transit routing number): 987654321
Standard Entry Class Code: CCD
Company Entry Description: HCCLAIMPMT
Effective Entry Date: February 19, 2015
12 | P a g e
1 2 3 4 5 6 7 8 9
12345678901234567890123456789012345678901234567890123456789012345678901234567890012345678901234
Example Data
5200ABHC CLM PMT CR 1234567891CCDHCCLAIMPMT 1502190001987654320000014
XML File Format
The payment method should be set to “TRF” for credit transactions and Service Level to “NURG,” or non-urgent
payment. Additionally, the local instrument code is used to identify the Standard Entry Class Code. In U.S. ACH
transactions, a routing number or ABA consisting of 9 digits is mandatory. The ABA corresponds to the clearing number,
and is used to identify the correct agent (or bank). As such, “USABA” must be entered before the ABA. Note that other
details of the record file are left out of this example.
Payment Information Block XML Message

<PmtInf>
<PmtInfId>011011</PmtInfId>
<PmtMtd>TRF</PmtMtd>
<PmtTpInf>
<SvcLvl>
Non-Urgent / ACH payment <Cd>NURG</Cd>
</SvcLvl>
<LclInstrm>
NACHA SEC Code <Cd>CCD</Cd>
</LclInstrm>
<CtgyPurp>
Company Entry Description <Prtry> HCCLAIMPMT</Prtry>
</CtgyPurp>
Effective Entry Date </PmtTpInf>
<ReqdExctnDt>2015-02-19</ReqdExctnDt>
13 | P a g e
Company Name <Dbtr>
<Nm>ABHC CLM PMT CR</Nm>
<Id>
<OrgId>
<Othr>
Company Identification <Id>1234567891</Id>
</Othr>
</OrgId>
</Id>
</Dbtr>
<DbtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
Originating DFI Identification <MmbId>987654321</MmbId>
</ClrSysMmbId>
<Nm>USA BANK</Nm>
</FinInstnId>
</DbtrAgt>
</PmtInf>
Example 3: Entry Detail Record “6”
Receiving DFI Identification (RDFI bank transit routing number): 11100002

Check Digit: 5
DFI Account Number (receiver’s bank account number): 4854697999999
Amount: $100.00
Receiving Company Name: DoogieHowserFamilyPrac
Identification Number: HowserMD1234567
14 | P a g e
1 2 3 4 5 6 7 8 9
12345678901234567890123456789012345678901234567890123456789012345678901234567890012345678901234
Example Data
6221110000254854697999999 0000010000HowserMD1234567DoogieHowserFamilyPrac 1987654320000904
XML File Format
As previously noted, the ABA corresponds to the clearing number, and is used to identify the correct agent (or bank).
As such, “USABA” must be entered before the ABA. The name of the creditor (receiver) can be entered with a
maximum of 22 characters when making an ACH payment. The creditor account number (DFI account number) must
be entered with 1-17 characters. Note that other details of the record file are left out of this example.
Credit Transfer Transaction Information XML Message

<CdtTrfTxInf>
<PmtId>
Identification Number <EndToEndId>HowserMD1234567</EndToEndId>
</PmtId>
<Amt>
Amount <InstdAmt Ccy = "USD">100.00</InstdAmt>
</Amt>
<CdtrAgt>
<FinInstnId>
<ClrSysMmbId>
<ClrSysId>
<Cd>USABA</Cd>
</ClrSysId>
Receiving DFI Identification + Check Digit <MmbId>111000025</MmbId>
</ClrSysMmbId>
<Nm>AMERICA BANK</Nm>
15 | P a g e
<PstlAdr>
<Ctry>US</Ctry>
<PstlAdr>
</FinInstnId>
</CdtrAgt>
<Cdtr>
Receiving Company Name <Nm>DoogieHowserFamilyPrac</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
<Id>4854697999999</Id>
DFI Account Number </Othr>
</Id>
</CdtrAcct>
</CdtTrfTxInf>
16 | P a g e
f. ISO File Format Table
The payment initiation credit transfer 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 to NACHA file formats are
highlighted. Please pay attention to the column "Maps to NACHA Format Field" when
implementing support for credit transfer files 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.
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
[0..1] = optional, only one occurrence
[0..n] = optional and repetitive
{Or ... Or} indicates a choice of elements
 Type: identifies data type and size
17 | P a g e
 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
Payment Information (Batch) / Transaction Level – There are a number of

optional fields that may be populated at the payment level or the transaction
level. It is recommended that they are populated at the payment information
level if being used.
 Maps to NACHA Format Field: specifies whether each tag and data element
is applicable to NACHA SEC Code CCD, CTX, PPD, or Outbound IAT
 Mapping Guide: For a number of fields, please pay attention to the Usage
Rules that must be followed when implementing pain.001 credit transactions
files sent in the U.S. These are outlined throughout the document.
18 | P a g e
1) The Group Header
Group Header contains the identification information of the payment message.
XML Declaration
Maps to NACHA Format

ISO Field Name Content Description M/O Mapping Guide
Field
<?xml version=”1.0” encoding=”UTF-8”?> The XML header must follow the

This tag must always be
<Document recommendation from
placed before the group M
xmlns=”urn:iso:std:iso:20022:tech:xsd:PAIN.001.001.03” http://www.iso20022.org beginning with the
header tag
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> Declaration outlined
This tag must always be
Customer Credit Transfer Initiation <CstmrCdtTrfInitn> placed before the group M
header tag
Group Header Block
ISO Maps to 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
Unique identification, as
assigned by the initiating
party, and sent to the
Message next party in the chain
Max35Text
1.1 Identification ++ to unambiguously [1..1] M
<MsgId> identify the message
Note: This ID cannot be

reused on future files
1. ALL, File Header
Date and time that the Record, File Creation Creation Date Time must be split from the
Creation Date Time file was created Date (Record 1, Field 5) aggregate ISO data element into File
1.2 ++ [1..1] ISODateTime M
<CreDtTm> 2. File Header Record, File Creation Date and File Creation Time fields
YYYY-MM-DDThh:mm:ss Creation Time (Record respectively
1, Field 6)
19 | P a g e
Group Header Block

Index Field
If no other payment type included in the
Number of Total number of Max15
file and all transactions are accepted,
1.6 Transactions ++ individual transactions [1..1] NumericText M
would equal the Entry Count (All “6”
<NbOfTxs> contained in the file
records)
Total of all individual
If no other payment type included in the
amounts included in the Quantity
Control Sum file and all transactions are accepted,
1.7 ++ file [0..1] [Decimal O
<CtrlSum> would equal Total Credit Entry Dollar
(sum of Instructed Number]
Amount in File
Amount)
Initiating Party
Initiating Party of
Initiating Party payment message Usage rule: Name or Identification or both
1.8 ++ [1..1] M
<InitgPty> must be present
Empty tag
Name of the Initiating ALL, File Header Record, Map the first 23 characters from ISO
Name
9.1.0 +++ Party [0..1] Max140Text O Immediate Origin Name Initiating Party Name to Immediate Origin
<Nm>
(Record 1, Field 12) Name including spaces
Identification
Unique and
unambiguous way of
identifying an
Identification
9.1.12 +++ organisation or an [0..1] O
<Id>
individual person
Empty tag
Unique an unambiguous
Organisation way of identifying an
9.1.13
Identification ++++ organisation [1..1] M
{OR
<OrgId>
Empty tag
20 | P a g e
Group Header Block

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 organisation, as
assigned by an
Other
9.1.15 +++++ institution, using an [0..n] O
<Othr>
identification scheme
Empty tag
10-digit company number assigned by
Identification assigned ALL, File Header Record,
Identification Max35Text bank typically 9-digit tax ID preceded by
9.1.16 ++++++ by an institution [1..1] M Immediate Origin (Record
<Id> "1"
1, Field 4)
Name of the
9.1.17 Scheme Name ++++++ identification scheme [0..1]
O
<SchmeNm>
Empty tag
May include as part of File Header Record,
Name of the Immediate Origin (Record 1, Field 4)
identification scheme, in
9.1.18 Code +++++++ [1..1] Code
a coded form as M Set to: (Examples):
{OR <Cd>
published in an external “TXID” for Tax Identification Number
list “CUST” Customer Identification Number
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
Identification of a
9.1.21 Private Identification private person Usage Rule: If <OrgId> is populated,
++++ [1..1] M
OR} <PrvtId> <PrvtId> should not be populated
Empty tag
21 | P a g e
2) Payment Information
Payment Information contains elements related to the debit side of the transaction. The information is common to all
the credit transfers attached to this Payment Information.
Payment Information Block – This can occur multiple times

Index Field
Set of characteristics
that applies to the debit
side of the payment
Payment Information transactions included in
2.0 + [1..n] M
<PmtInf> the credit transfer
initiation
Empty tag
1. For CCD, PPD and CTX,
Batch Header Record,
Batch Number (Record 5,
Field 13) Originator assigns batch numbers in
Payment Information Originator’s unique
Max35Text 2. For IAT, Batch Header ascending order within each file
2.1 Identification ++ identifier of the batch of [1..1] M
Record, Batch Number
<PmtInfId> transactions
(Record 5, Field 17) May vary by bank and set by ODFI system
3. For ALL, Batch Control
Record, Batch Number
(Record 8, Field 11)
Specifies the means of
Payment Method payment that will be
2.2 ++ [1..1] Code M Set to “TRF” for Credit Transfers
<PmtMtd> used to move the
amount of money
Total number of
Number Of Max15 If all transactions are accepted would
individual transactions
2.4 Transactions ++ [0..1] NumericTex O equal to the Entry Count in the batch (All
contained in the
<NbOfTxs> “6” records)
message
Total of all individual If all transactions are accepted, would
amounts included Quantity
Control Sum equal Total Credit Entry Dollar Amount in
2.5 ++ in the batch [0..1] [Decimal O
<CtrlSum> the batch
(sum of Instructed Number]
Amount)
22 | P a g e

Index Field
Payment Type Information
Set of elements that
Payment Type further specifies the type
2.6 Information ++ of transaction [0..1] O
<PmtTpInf>
Empty tag
Agreement under which
or rules under which the
Service Level transaction should be [0..1]
2.8 +++ O
<SvcLvl> processed
Empty tag
Specifies a pre-agreed
service or level of service
2.9 Code Set to “NURG” for payment executed as
++++ between the parties, as [1..1] Code M
{OR <Cd> non-urgent payment
published in an external
service level code list
2.10 Proprietary service or level of service Max35Text Usage Rule: If <Cd> is populated, <Prtry>
++++ [1..1] M
OR} <Prtry> between the parties, as should not be populated
a proprietary code
User community specific
Local Instrument instrument
2.11 +++ [0..1] O
<LclInstrm>
Empty tag
1. For CCD/CCD+, set Local Instrument
1. For CCD , PPD and CTX, Code value to "CCD"
Batch Header Record, For PPD/PPD+, set Local Instrument Code
Specifies the local Standard Entry Class value to "PPD"
2.12 Code instrument as published Code (Record 5, Field 6) For CTX, set Local Instrument Code value
++++ [1..1] Code M
{OR <Cd> in an external local 2. For IAT, Batch Header to " CTX"
instrument code list Record, Standard Entry 2. For IAT, set Local Instrument Code value
Class Code (Record 5, to " IAT"
Field 9)
Specifies the local

2.13 Proprietary Max35Text Usage Rule: If <Cd> is populated, <Prtry>
++++ instrument as a [1..1] M
proprietary code
23 | P a g e

Index Field
Specifies the high level
purpose of the
instruction based on a
set of pre-defined
categories. This is used
by the initiating party
to provide information
Category Purpose concerning the
2.14 +++ [0..1] O
<CtgyPurp> processing of the
payment. It is likely to
trigger special
processing by any of the
agents involved in the
payment chain
Empty tag
Category purpose, as
2.15 Code Usage Rule: If <Prtry> is populated, <Cd>
++++ category purpose code [1..1] Code M
{OR <Cd> should not be populated
list

Batch Header Record, Field used by the originator to describe the
Company Entry transaction for the receiver e.g. PAYROLL or
Description (Record 5, TRADE PAY
2.16 Proprietary Category purpose, in a Max35Text
++++ [1..1] M Field 7)
OR} <Prtry> proprietary form
2. For IAT, Batch Header Note preferable to avoid <Proprietary> and
Record, Company Entry use applicable <Code> from External
Description (Record 5, Code List if possible
Field 10)
Date the
Effective Entry Date
Requested Execution payee/beneficiary is to
2.17 ++ [1..1] ISODate M (Record 5, Field 9)
Date <ReqdExctnDt> receive the payment
2. For IAT, Batch Header
YYYY-MM-DD
Record, Effective Entry
Date (Record 5, Field 13)
24 | P a g e

Index Field
Party that owes an
amount of money to the
Debtor
2.19 ++ (ultimate) creditor [1..1] M
<Dbtr>
Empty tag
1. Map the first 16 characters from ISO
1. For CCD, PPD & CTX,
Debtor Name to the company name for
CCD, PPD & CTX
Company Name
2. Map the first 35 characters from ISO
Name Name of the Max140Text (Record 5, Field 3)
9.1.0 +++ [0..1] M Debtor Name to the company name for
<Nm> payer/originator 2. For IAT, Second IAT
IAT (For 3rd party payment i.e., payment
Addenda Record,
on behalf of, map to <UltimateDebtor>
Originator Name
<Name>)
(Record 7, Field 3)
Usage Rule: Preference by following order:
1. Use only structured address
2. When using combination of both
structured address and Address Line,
must use structured tags for post code (if
applicable), town name and country
Information that locates
and identifies a specific and only 2 Address Lines max 35
Postal Address address, as defined by characters each (to include street
9.1.1 +++ [0..1] O
<PstlAdr> postal services address and town name)
3. Use only Address Line, up to 7 lines
Empty tag
NOTE: PO Box and c/o address should only
appear in Address Line
For 3rd party payment i.e., payment on

behalf of, address information map to
<UltimateDebtor> fields
Address Type Identifies the nature of
9.1.2 ++++ [0..1] Code O
<AdrTp> the postal address
Identification of a
Department Max70Text
9.1.3 ++++ division of a large [0..1] O
<Dept>
organisation or building
Identification of a sub-
Sub Department Max70Text
9.1.4 ++++ division of a large [0..1] O
<SubDept>
25 | P a g e
Payment Information Block – This can occur multiple times within a file

Index Field
For IAT, Second IAT
Name of a street or
Street Name Max70Text Addenda Record,
9.1.5 ++++ thoroughfare [0..1] O
<StrtNm> Originator Street Address
(Record 7, Field 4)
Number that identifies For IAT, Second IAT
Building Number the position of a building Max16Text Addenda Record,
9.1.6 ++++ [0..1] O
<BldgNb> on a Originator Street Address
street (Record 7, Field 4)
Identifier consisting of a
For IAT, Third IAT Addenda
group of letters and/or
Post Code Max16Text Record, Originator Country
9.1.7 ++++ numbers that is added [0..1] O
<PstCd> & Postal Code (Record 7,
to a postal address to
Field 4)
assist the sorting of mail
Name of a built-up area, For IAT, Third IAT Addenda
Town Name with defined boundaries, Max35Text Record, Originator City &
9.1.8 ++++ [0..1] O
<TwnNm> and a local government State/Province (Record 7,
Field 3)
Identifies a subdivision of For IAT, Third IAT Addenda
Country Sub Division a country e.g., state, Max35Text Record, Originator City &
9.1.9 ++++ [0..1] O
<CtrySubDvsn> region, country State/Province (Record 7,
Field 3)
For IAT, Third IAT Addenda
Nation with its own
Country Record, Originator Country
9.1.10 ++++ government [0..1] Code O
<Ctry> & Postal Code (Record 7,
Field 4)
and identifies a specific
May map to <AddressLine> for IAT, Second
Address Line address, as defined by Max70Text
9.1.11 ++++ [0..7] O and Third Addenda Records in lieu of
<AdrLine> postal services, that is
specific address fields
presented in free format
text
Identification
Unique and
unambiguous way of
identifying an
Identification
9.1.12 +++ organisation or an [0..1] O
<Id>
individual person
Empty tag
26 | P a g e

Index Field
Unique and
Organisation unambiguous way to
9.1.13
Identification ++++ identify an organization [1..1]
{OR
<OrgId>
Empty tag
Code allocated to
9362 Registration
Authority, under an
international
BIC Or BEI identification scheme, as Usage Rule: If <Othr> is populated,
9.1.14 Identifier
<BICOrBEI> ++++ described in the latest [0..1] O <BICOrBEI> should not be populated
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
1. For CCD, PPD & CTX,
Company Identification
(Record 5, Field 5)
Identification Identification assigned Max35Text Record, Originator 10-digit ID assigned by the bank
9.1.16 ++++++ [1..1] M
<Id> by an institution Identification (Record 5,
Field 8)
3. For ALL, Batch Control
Record, Company
Identification (Record 8,
Field 7)
Name of the
9.1.17 Scheme Name ++++++ identification scheme [0..1]
O
<SchmeNm>
Empty tag
27 | P a g e

Index Field
May include as part of CCD, PPD & CTX
Batch Header Record, Company
Identification (Record 5, Field 5); Batch
Control Record, Company Identification
Name of the
(Record 8, Field 7); or as part of IAT Batch
identification scheme, in
9.1.18 Code +++++++ [1..1] Code Header Record, Originator Identification
a coded form as M
{OR <Cd> (Record 5, Field 8)
list
Set to: (Examples):
“TXID” for Tax Identification Number
“CUST” Customer Identification Number
Name of the
9.1.19 Proprietary +++++++ [1..1] Max35Text Usage Rule: If <Cd> is populated, <Prtry>
identification scheme, in M
a free text form
Unique and
unambiguous
9.1.21 Private Identification Usage Rule: If <OrgId> is populated,
++++ identification of a [1..1] M
OR} <PrvtId> <PrvtId> should not be populated
private person, e.g.,
passport
Unambiguous
identification of the
account of the debtor
Debtor Account
2.20 ++ to which a debit entry [1..1] M
<DbtrAcct>
will be made as a result
of the transaction
Empty tag
For IAT, Batch Header
Identification of the The 3-character Debtor Account Currency
Currency Record, ISO Originating
1.1.11 +++ currency in which the [0..1] Code O maps to the ISO Originating Currency
<Ccy> Currency Code (Record 5,
account is held Code e.g., “USD”
Field 11)
Financial institution
servicing an account for
Debtor Agent
2.21 ++ the debtor [1..1] M
<DbtrAgt>
Empty tag
28 | P a g e

Index Field
Unique and
unambiguous identifier
of a financial institution,
Financial Institution as assigned under an
6.1.0 Identification +++ internationally [1..1] M
<FinInstnId> recognised or
proprietary identification
scheme
Empty tag
Bank Identifier Code.
Code allocated to
financial institutions by
the Registration
Authority, under an
international
BIC identification scheme, as BICIdentifier Usage Rule: Either <BIC> or <ClrSysMmbId>
6.1.1 ++++ [0..1] O
<BIC> described in the latest must be populated
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
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
29 | P a g e

Index Field
Specifies the Clearing For IAT, Fourth IAT
Set to “USABA”
System Member Addenda Record,
6.1.4 Code
+++++ Identification as [1..1] Code M Originating DFI
{OR <Cd> If <Cd> is present, set Originating DFI
published in an external Identification Number
Identification Number Qualifier to “01”
local instrument code list Qualifier (Record 7, Field 4)
Specifies the Clearing
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
1. For ALL, File Header
Record, Immediate
Destination (Record 1,
Field 3)
Company Batch Header,
Originating DFI
Identification (Record 5, Originating DFI ABA or transit routing
Field 12) number assigned preceded by a blank
3. For IAT, Company Batch space
Member
Bank clearing code or Max35Text Header, Originating DFI
6.1.6 Identification +++++ [1..1] M
transit routing number Identification (Record 5, 2, 3, and 4 maps to the first 8 digits (drop
<MmbId>
Field 16) the last or 9th digit)
4. For ALL, Batch/Control
Record, Originating DFI
Field 10)
5. For IAT, Fourth IAT
Addenda Record,
Originating DFI
Field 5)
30 | P a g e

Index Field
1. For ALL, File Header
Record, Immediate 1. Map the first 23 characters from ISO
Destination Name Debtor Agent Name to Immediate
Identifies the bank
Name (Record 1, Field 11) Destination Name
6.1.7 ++++ processing the [0..1] Max140Text O
<Nm> 2. For IAT, Fourth IAT 2. Map the first 35 characters from ISO
transaction
Addenda Record, Debtor Agent Name to Originating DFI
Originating DFI Name Name
(Record 7, Field 3)
structured address and Address Line,
Information that locates must use structured tags for post code (if
applicable), town name and country
Postal Address address, as defined by
6.1.8 ++++ [0..1] O and only 2 Address Lines max 35
<PstlAdr> postal services
characters each (to include street
Empty tag address and town name)


6.1.9 +++++ [0..1] Code O
Identification of a
6.1.10 +++++ division of a large [0..1] O
<Dept>
organisation or
building
6.1.11 Sub Department Max70Text
+++++ division of a large [0..1] O
<SubDept>
6.1.12 Street Name Name of a street or Max70Text

+++++ [0..1] O
<StrtNm> thoroughfare
31 | P a g e

Index Field
Number that identifies
Building Number the position of a building Max16Text
6.1.13 +++++ [0..1] O
<BldgNb> on a
street
Post Code Max16Text
6.1.14 +++++ numbers that is added [0..1] O
<PstCd>
Name of a built-up area,
Town Name Max35Text
6.1.15 +++++ with defined boundaries, [0..1] O
<TwnNm>
and a local government
Identifies a subdivision of
Country Sub Division Max35Text
6.1.16 +++++ a country e.g., state, [0..1] O
<CtrySubDvsn>
region, country
For IAT, Fourth IAT
Nation with its own Addenda Record,
Country
6.1.17 +++++ government [0..1] Code O Originating DFI Branch “US” is present
<Ctry>
Country Code (Record 7,
Field 6)
6.1.18 +++++ [0..7] O
text
Other
6.1.19 ++++ Empty tag [0..1] O
<Othr>
Identification
6.1.20 +++++ e.g., IBAN [1..1} M
<Id>
32 | P a g e
3) Credit Transfer Transaction Information
Credit Transfer Transaction Information contains elements related to the transaction.
Credit Transfer Transaction Information Definition: Set of elements used to provide information on the individual transaction(s) included in the message

Index Field
Set of elements
Credit Transfer providing information
Transaction specific to the individual
2.27 ++ transaction(s) included [1..n] M
Information
<CdtTrfTxInf> in the message
Empty tag
Set of elements to
Payment reference a payment
2.28 Identification +++ instruction. [1..1] M
<PmtId>
Empty tag
Unique identification as
assigned by an
instructing party for an
Instruction Usage Rule: If present, ID to be returned
instructed
2.29 Identification ++++ [0..1] Text O only to the originating party in account
party to unambiguously
<InstrId> statement reporting
identify the instruction. It
is not forwarded to the
creditor’s bank
1. For CCD, PPD and CTX ,
Originator’s Reference
Entry Detail Record,
to the Credit Transfer
Identification Number
to unambiguously
End To End (Record 6, Field 7) Usage rule: Payment Reference that goes
identify the transaction.
2.30 Identification ++++ [1..1] Text M 2. For IAT, Sixth IAT with the payment from debtor to creditor
This identification is
<EndToEndId> Addenda Record, and travels throughout the clearing system
passed on, unchanged,
Receiver Identification
throughout the entire
Number (Record 7,
end-to-end chain
Field 3)
Payment Type Information This is optional and if used, it is recommended to be used at Payment Information level and not at Credit Transfer Transaction Information level. However, if
‘Instruction Priority’ is populated this field group must be present at ‘Payment Information’ level and not at transaction information level.
Set of elements that
Payment Type further specifies the type
2.31 Information +++ of transaction [0..1] O
<PmtTpInf>
Empty tag
33 | P a g e

Index Field
Agreement under which
or rules under which the
Service Level transaction should be [0..1]
2.33 ++++ O
<SvcLvl> processed
Empty tag
service or level of service
2.34 Code Set to “NURG” for payment executed as
+++++ between the parties, as [1..1] Code M
{OR <Cd> non-urgent payment
service level code list
2.35 Proprietary service or level of service Max35Text Usage Rule: If <Cd> is populated, <Prtry>
+++++ [1..1] M
OR} <Prtry> between the parties, as should not be populated
a proprietary code
Local Instrument instrument
2.36 ++++ [0..1] O
<LclInstrm>
Empty tag
1. For CCD, PPD and CTX, 1. For CCD/CCD+, set Local Instrument
Batch Header Record, Code value to "PPD"
Specifies the local Standard Entry Class For PPD/PPD+, set Local Instrument Code
2.37 Code instrument as published Code (Record 5, Field 6) value to "PPD"
+++++ [1..1] Code M For CTX, set Local Instrument Code value
{OR <Cd> in an external local 2. For IAT, Batch Header
instrument code list Record, Standard Entry to "CTX"
Class Code (Record 5, 2. For IAT, set Local Instrument Code value
Field 9) to “IAT"
Specifies the local

2.38 Proprietary Usage Rule: If <Cd> is populated, <Prtry>
+++++ instrument as a [1..1] Max35Text M
proprietary code
Specifies the high level

purpose of the
Category Purpose instruction based on a
2.39 ++++ set of pre-defined [0..1] O
<CtgyPurp>
categories
Empty tag
Specifies Category
2.40 Code purpose as published in Usage Rule: If <Prtry> is populated, <Cd>
+++++ [1..1] Code M
{OR <Cd> an external category should not be populated
purpose code list
34 | P a g e

Index Field
Field used by the originator to describe the
transaction for the receiver e.g. PAYROLL or
Company Entry
TRADE PAY
Specifies Category Description (Record 5,
2.41 Proprietary
purpose as a [1..1] Max35Text M Field 7)
OR} <Prtry> Note preferable to avoid <Proprietary> and
proprietary code 2. For IAT, Batch Header
use applicable <Code> from External
Record, Company Entry
Code List if possible
Description (Record 5,
Field 10)
Amount of money to be
Amount moved between the
2.42 +++ debtor and creditor [1..1] M
<Amt>
Empty tag
Record, Foreign
Exchange Indicator
(Record 5, Field 4)
2. For IAT, Batch Header e.g., <InstdAmt
Record, ISO Destination Ccy="EUR">50000.00</InstdAmt>
Currency Code (Record
5, Field 12) If <InstructedAmount> present, set Foreign
Instructed Amount The amount to be paid
3. For CCD, PPD and CTX, Exchange Indicator to “FF”
2.43 <InstdAmt in full to the payee/
++++ [1..1] Amount M Entry Detail Record,
{OR Ccy="AAA"> beneficiary
Amount (Record 6, Field Usage Rule:
6) If <InstdAmt> is populated, <EqvtAmt >
4. For IAT, Entry Detail should not be populated
Record, Amount (Record
6, Field 7)
5. For IAT, First IAT Addenda
Record, Foreign Payment
Amount (Record 7, Field
4)
Amount of money to be
Usage Rule:
transferred between the
2.44 Equivalent Amount If <EqvtAmt> is populated, <InstdAmt>
++++ debtor and creditor [1..1] Amount M
OR} <EqvtAmt> should not be populated
Empty tag
35 | P a g e

Index Field
Record, Foreign
Exchange Indicator
Amount Amount of money to be (Record 5, Field 4)
If <AmountCurrency> present, set Foreign
2.45 <Amt Ccy="AAA"> +++++ transferred between [1..1] Amount M 2. For IAT, First IAT
Exchange Indicator to “FV”
debtor and creditor Addenda Record,
Foreign Payment
Amount (Record 7, Field
4)
Specifies the currency of
e.g., <EqvtAmt>
the to be transferred For IAT, Batch Header
<Amt Ccy="USD">50000.00</Amt>
Currency Of Transfer amount, which is Record, ISO Destination
2.46 +++++ [1,1] Code M <CcyOfTrf>EUR</CcyOfTrf>
<CcyOfTrf> different from the Currency Code (Record
</EqvtAmt>
currency of the debtor’s 5, Field 12)
account
Further detailed
information on the
Exchange Rate exchange rate specified
2.47 Information +++ in the payment [0..1] O
<XchgRateInf> transaction
Empty tag
The factor used for
Record, Foreign 1. If <ExchangeRate> present, set Foreign
conversion of an
Exchange Reference Exchange Reference Indicator to “1”
amount from one
Indicator (Record 5, Field 1 & 2. If neither <ExchangeRate> nor
Exchange Rate currency to another. This
2.48 ++++ [0..1] Rate O 5) <ContractIdentification> are present, set
<XchgRate> reflects the price at
2. For IAT, Batch Header Foreign Exchange Reference Indicator to
which one currency was
Record, Foreign “3” and Foreign Exchange Reference
bought with another
Exchange Reference should be set to blank
currency
(Record 5, Field 6)
Usage Rule: If Code AGRD (Exchange rate
applied is the rate agreed with the bank) is
used then a valid contract number must be
Specifies the type used
Rate Type filled in tag 2.50
2.49 ++++ to complete the [0..1] Code O
<RateTp>
currency exchange
Other values for <Rate Type>:
"SALE" = market rate at the time of the sale
"SPOT” = spot rate
36 | P a g e

Index Field
Unique and If <ContractIdentification> present, set
Record, Foreign
unambiguous reference Foreign Exchange Reference Indicator to
Contract Exchange Reference
to the foreign exchange “2”
Identification (Record 5, Field 5)
2.50 ++++ contract agreed [0..1] Text O
<CtrctId> 2. For IAT, Batch Header
between the initiating Usage Rule: If code AGRD is used in tag
Record, Foreign
party/creditor and the 2.49 then this field must contain a valid
Exchange Reference
debtor agent contract number agreed
(Record 5, Field 6)
Agent between the
IntermediaryAgent1 debtor agent and
2.71 +++ creditor agent [0..1] O
<IntrmyAgt1>
Empty tag
Unique and
6.1.0 Identification ++++ internationally [1..1] M
scheme
Empty tag
Code allocated to
the Registration
Authority, under an
international
BIC identification scheme, as BICIdentifier
6.1.1 +++++ [0..1] O
<BIC> described in the latest
ISO 9362 Banking
(Banking
telecommunication
Codes)
37 | P a g e

Index Field
Unique and
6.1.2 +++++ [0..1] O
<ClrSysMmbId> administrator
Empty tag
agreed offering
between clearing
6.1.3 Identification ++++++ through which the [0..1] O
processed
Empty tag
Identification of a
Set to “USABA”
6.1.4 Code clearing system in a
+++++++ [1..1] Code M
{OR <Cd> coded form as published
in an external list
Identification code for a
clearing system that has
6.1.5 Proprietary Max35Text Usage Rule: If <Cd> is populated,
+++++++ not yet been identified [1..1] M
OR} <Prtry> <Prtry> should not be populated
in the list of clearing
systems
1. For IAT, Entry Detail
Record, Gateway
Member Identification of a Operator (GO) Note that Field 3 and 4 are combined for
Identification member of a clearing Max35Text Identification (Record 6 , Record 6 as the Check Digit is the last (or
6.1.6 ++++++ [1..1] M
<MmbId> system Field 3) 9th) digit of the transit routing number
2. For IAT, Entry Detail
Record, Check Digit
(Record 6 , Field 4)
Agent between the
debtor agent and
Intermediary Agent2
<IntrmyAgt2>
Empty tag
38 | P a g e

Index Field
Unique and
as assigned under an
Financial Institution
internationally
6.1.0 Identification ++++ [1..1] M
recognised or
<FinInstnId>
scheme
Empty tag
Code allocated to 1. For IAT, Addenda For
financial institutions by Foreign Correspondent
the Registration Bank Information
Authority, under an (Record 7, Field 4)
international 2. For IAT, Addenda Record
If <BIC> is present, set Foreign
BIC identification scheme, as BICIdentifier For Foreign
6.1.1 +++++ [0..1] O Correspondent Bank Identification Number
<BIC> described in the latest Correspondent Bank
Qualifier to “02”
version of the standard Information, Foreign
ISO 9362 Banking Correspondent Bank
(Banking Identification Number
telecommunication (Record 7, Field 5)
Codes)
Unique and
6.1.2 +++++ [0..1] O
Empty tag
agreed offering
between clearing
processed
Empty tag
39 | P a g e

Index Field
For IAT, Addenda For
Identification of a Foreign Correspondent
6.1.4 Code clearing system in a Bank Information, Foreign If <Cd> is present, set Foreign
+++++++ [1..1] Code M
{OR <Cd> coded form as published Correspondent Bank Correspondent Bank Identification Number
in an external list Identification Number Qualifier to “01”
Qualifier (Record 7, Field 4)
clearing system that has
systems
For IAT, Addenda Record
May map to <IntermediaryAgent2> or
Member Identification of a For Foreign Correspondent
<IntermediaryAgent3>
Identification member of a clearing Max35Text Bank Information, Foreign
6.1.6 ++++++ [1..1] M <MemberIdentification> to Foreign
<MmbId> system Correspondent Bank
Correspondent Bank Identification Number
(Record 7, Field 5)
Name by which a party
For Foreign Correspondent May map <IntermediaryAgent2> or
Name is known and which is Max140Text
6.1.7 +++++ [0..1] O Bank Information, Foreign <IntermediaryAgent3><Name> to Foreign
<Nm> usually used to identify
Correspondent Bank Name Correspondent Bank Name
that party
(Record 7, Field 3)
Information that locates 2. When using combination of both

and identifies a specific structured address and Address Line, must
Postal Address address, as defined by use structured tags for post code (if
6.1.8 +++++ [0..1] O applicable), town name and country and
only 2 Address Lines max 35 characters
each (to include street address and town
Empty tag
name)

40 | P a g e

Index Field
Identifies the nature of
Address Type
6.1.9 ++++++ the postal address [0..1] Code O
<AdrTp>
Identification of a
6.1.10 ++++++ division of a large [0..1] O
<Dept>
<SubDept>
Street Name Name of a street or Max70Text
6.1.12 ++++++ [0..1] O
6.1.13 ++++++ [0..1] O
<BldgNb> on a
Street
Post Code Max16Text
6.1.14 ++++++ numbers that is added [0..1] O
<PstCd>

Town Name Max35Text
6.1.15 ++++++ with defined boundaries, [0..1] O
<TwnNm>
6.1.16 ++++++ a country e.g., state, [0..1] O
<CtrySubDvsn>
region, country

for Foreign Correspondent
Nation with its own
Country Bank Information, Foreign
6.1.17 ++++++ government [0..1] Code O
<Ctry> Correspondent Bank
Branch Country Code
(Record 7, Field 6)
41 | P a g e

Index Field
6.1.18 ++++++ [0..7] O
text
Agent between the
Intermediary Agent2 debtor agent and
2.73 Account +++ creditor agent [0..1] O
<IntrmyAgt2Acct>
Empty tag
Unique and
unambiguous
identification for the
Identification account between the
1.1.0 ++++ [1..1] M
<Id> account owner and the
account servicer
Empty tag
1. For IAT, Addenda For
Foreign Correspondent
Bank Information,
International Bank
Bank Identification
Account Number (IBAN)
Number Qualifier
- identifier used
1.1.1 IBAN (Record 7, Field 4) If <Cd> is present, set Foreign
+++++ internationally by [1..1] Identifier M
{OR <IBAN> 2. For IAT, Addenda Record Correspondent Bank Identification Number
financial institutions to
For Foreign Qualifier to “03”
uniquely identify the
Correspondent Bank
account of a customer
Information, Foreign
Correspondent Bank
(Record 7, Field 5)
42 | P a g e

Index Field
an account, as assigned
1.1.2 Other Usage Rule: If <IBAN> is populated,
+++++ by the account servicer, [1..1] M
OR} <Othr> <Othr> should not be populated
using an identification
scheme
Agent between the
debtor agent and
Intermediary Agent3
<IntrmyAgt3>
Empty tag
Unique and
6.1.0 Identification ++++ internationally [1..1] M
scheme
Empty tag
Code allocated to 1. For IAT, Addenda
financial institutions by Record for Foreign
the Registration Correspondent Bank
Authority, under an Information Record
international (Record 7, Field 4)
If <BIC> is present, set Foreign
BIC identification scheme, as BICIdentifier 2. For IAT, Addenda
6.1.1 +++++ [0..1] O Correspondent Bank Identification Number
<BIC> described in the latest Record For Foreign
version of the standard Correspondent Bank
ISO 9362 Banking Information, Foreign
(Banking Correspondent Bank
telecommunication Identification Number
messages, Bank Identifier (Record 7, Field 5)
Codes)
Unique and
6.1.2 +++++ [0..1] O
Empty tag
43 | P a g e

Index Field
agreed offering
between clearing
processed
Empty tag
Identification of a for Foreign Correspondent
6.1.4 Code clearing system, in a Bank Information, Foreign
+++++++ [1..1] Code M If <Cd> is present, set Foreign
{OR <Cd> coded form as published Correspondent Bank
Correspondent Bank Identification Number
in an external list Identification Number
clearing system, that has
systems
Member Identification of a for Foreign Correspondent May map to <IntermediaryAgent2> or
Identification member of a clearing Max35Text Bank Information, Foreign <IntermediaryAgent3>
6.1.6 ++++++ [1..1] M
<MmbId> system Correspondent Bank <MemberIdentification> to Foreign
Identification Number Correspondent Bank Identification Number
(Record 7, Field 5)
Name by which a party
for Foreign Correspondent May map <IntermediaryAgent2> or
Name is known and which is Max140Text
6.1.7 +++++ [0..1] O Bank Information, Foreign <IntermediaryAgent3><Name> to Foreign
<Nm> usually used to identify
Correspondent Bank Name Correspondent Bank Name
that party
(Record 7, Field 3)
44 | P a g e

Index Field
structured address and Address Line, must
Information that locates use structured tags for post code (if
and identifies a specific applicable), town name and country and
6.1.8 +++++ [0..1] O only 2 Address Lines max 35 characters
<PstlAdr> postal services each (to include street address and town
Empty tag name)

Identifies the nature of
Address Type
6.1.9 ++++++ the postal address [0..1] Code O
<AdrTp>
Identification of a
<Dept>
<SubDept>
6.1.12 ++++++ [0..1] O
6.1.13 ++++++ [0..1] O
<BldgNb> on a
Street
Post Code Max16Text
<PstCd>

Town Name Max35Text
<TwnNm>
<CtrySubDvsn>
region, country
45 | P a g e

Index Field
for Foreign Correspondent
Nation with its own
Country Bank Information, Foreign
6.1.17 ++++++ government [0..1] Code O
<Ctry> Correspondent Bank
Branch Country Code
(Record 7, Field 6)
6.1.18 ++++++ [0..7] O
text
Agent between the
Intermediary Agent3 debtor agent and
<IntrmyAgt2Acct>
Empty tag
Unique and
unambiguous
Identification account between the Max35Text
1.1.0 ++++ [1..1] M
account servicer
Empty tag
1. For IAT, Addenda For
Bank Information,
International Bank
Bank Identification
Number Qualifier
- identifier used
1.1.1 IBAN (Record 7, Field 4) If <Cd> is present, set Foreign
+++++ internationally by [1..1] Identifier M
{OR <IBAN> 2. For IAT, Addenda Record Correspondent Bank Identification Number
For Foreign Qualifier to “03”
Correspondent Bank
Information, Foreign
Correspondent Bank
(Record 7, Field 5)
46 | P a g e

Index Field
1.1.2 Other Usage Rule: If <IBAN> is populated,
+++++ by the account servicer, [1..1] M
OR} <Othr> <Othr> should not be populated
scheme
Creditor Agent Information
Financial institution
servicing an account for
Creditor Agent
2.77 +++ the creditor [0..1] O
<CdtrAgt>
Empty tag
Unique and
as assigned under an
Financial Institution
internationally
6.1.0 Identification ++++ [1..1] M
recognised or
<FinInstnId>
scheme
Empty tag
Code allocated to
1. For IAT, Fifth IAT
Addenda Record,
the Registration
Receiving DFI
Authority, under an
international
Qualifier (Record 7, Field
BIC identification scheme, as BICIdentifier If <BIC> is present, set Receiving DFI
6.1.1 +++++ [0..1] O 4)
<BIC> described in the latest Identification Number Qualifier to “02”
2. For IAT, Fifth IAT
Addenda Record,
ISO 9362 Banking
Receiving DFI
(Banking
telecommunication
(Record 7, Field 5)
Codes)
Unique and
Clearing System
of a clearing system
Member
6.1.2 +++++ member, as assigned by [0..1] O
Identification
the system or system
<ClrSysMmbId>
administrator
Empty tag
47 | P a g e

Index Field
agreed offering
between clearing
processed
Empty tag
For IAT, Fifth IAT Addenda
System Member
6.1.4 Code Record, Receiving DFI If <Cd> is present, set Receiving DFI
+++++ Identification as [1..1] Code M
{OR <Cd> Identification Number Identification Number Qualifier to “01”
local instrument code list
6.1.5 Proprietary System Member Usage Rule: If <Cd> is populated,
+++++ [1..1] Max35Text M
OR} <Prtry> Identification as a <Prtry> should not be populated
proprietary code
1. For CCD, PPD &CTX, Entry
Detail Record, Receiving
1. The first 8 digits of <MemberIdentification>
DFI Identification (Record
map to the Receiving DFI Identification
6 , Field 3)
Member 2. Note that Field 3 and 4 are combined for
2. For CCD, PPD & CTX, Entry
Identification Bank clearing code or Record 6 as the Check Digit is the last (or
6.1.6 ++++++ [1..1] Max35Text M Detail Record, Check
<MmbId> transit routing number 9th) digit of the transit routing number
Digit (Record 6 , Field 4)
3. The first 34 digits of
3. For IAT, Sixth Addenda
<MemberIdentification> map to the
Record, Receiving DFI
Receiving DFI Identification
Identification (Record 7 ,
Field 5)
Name of the Receiving For IAT, Fifth IAT Addenda
Name
6.1.7 +++++ Depository Financial [0..1] Max140Text O Record, Receiving DFI
<Nm>
Institution Name (Record 7, Field 3)
48 | P a g e

Index Field
use structured tags for post code (if
applicable), town name and country and
6.1.8 +++++ only 2 Address Lines max 35 characters
each (to include street address and town
name)
Empty tag


6.1.9 ++++++ [0..1] Code O
Identification of a
<Dept>
<SubDept>
6.1.12 ++++++ [0..1] O
6.1.13 ++++++ [0..1] O
<BldgNb> on a
street
Post Code group of letters and/or Max16Text
6.1.14 ++++++ [0..1] O
<PstCd> numbers that is added
Town Name Max35Text
<TwnNm>
<CtrySubDvsn>
region, country
49 | P a g e

Index Field
Record, ISO Destination
Country Code (Record 5,
Country Nation with its own Field 7)
6.1.17 ++++++ [0..7] Code O
<Ctry> government 2. For IAT, Fifth IAT
Addenda Record, ISO
DFI Branch Country
Code (Record 7, Field 6)
6.1.18 ++++++ [0..7] O
text
Agent between the
Creditor Agent debtor agent and
<CdtrAgtAcct>
Empty tag
Unique and
unambiguous
Identification account between the Max35Text
1.1.0 ++++ [1..1] M
account servicer
Empty tag
International Bank
For IAT, IAT Addenda For
- identifier used If <Cd> is present, set Foreign
1.1.1 IBAN Bank Information, Foreign
+++++ internationally by [1..1] Identifier M Correspondent Bank Identification
{OR <IBAN> Correspondent Bank
financial institutions to Number Qualifier to “03”
an account, as assigned Usage Rule: If <IBAN> is populated,
1.1.2 Other
+++++ by the account servicer, [1..1] M <Othr> should not be populated
OR} <Othr>
scheme
50 | P a g e

Index Field
Creditor Information
Party to which the
Creditor amount of money is due
2.79 +++ [0..1] O
<Cdtr>
Empty tag
1. For CCD & PPD, Entry 1. For CCD and PPD, map the first 22
Detail Record, Receiving characters from ISO Creditor Name to
Company Name (Record Receiving Company
6, Field 8) Name
2. For CTX, Entry Detail 2. For CTX, map the first 16 characters from
Record, Receiving ISO Creditor Name to Receiving
Name
9.1.0 ++++ Name of the Creditor [0..1] Text O Company Name (Record Company Name
<Nm>
6, Field 9) 3. For IAT, map the first 35 characters from
3. For IAT, First IAT Addenda ISO Creditor Name to Receiving
Record, Receiving Company/Individual Name (For 3rd party
Company payment i.e., ultimate beneficiary of
Name/Individual Name payment, maps to
(Record 7, Field 6) <UltimateCreditor><Name>)
use structured tags for post code (if
applicable), town name and country and
Information that locates only 2 Address Lines max 35 characters
and identifies a specific each (to include street address and town
Postal Address address, as defined by name)
9.1.1 ++++ [0..1] Code O
<PstlAdr> postal services 3. Use only Address Line, up to 7 lines
Empty tag NOTE: PO Box and c/o address should only

For 3rd party payment i.e., ultimate

beneficiary of payment, address
information map to <UltimateCreditor>
fields
Address Type Identifies the nature of Max70Text
9.1.2 +++++ [0..1] O
Identification of a
<Dept>
51 | P a g e

Index Field
<SubDept>
For IAT, Sixth IAT Addenda
9.1.5 +++++ [0..1] O Record, Receiver Street
Address (Record 7, Field 4)
For IAT, Sixth IAT Addenda
9.1.6 +++++ [0..1] O Record, Receiver Street
<BldgNb> on a
Address (Record 7, Field 4)
street
For IAT, Seventh IAT
Post Code Max16Text Addenda Record,
<PstCd> Receiver Street Address
(Record 7, Field 4)
Town Name Max35Text Addenda Record,
<TwnNm> Receiver Street Address
(Record 7, Field 3)
Country Sub Division Max35Text Addenda Record,
<CtrySubDvsn> Receiver Street Address
region, country
(Record 7, Field 3)
Addenda Record,
Country Nation with its own
9.1.10 ++++++ [0..7] Code O Receiver Street Address
<Ctry> government
(Record 7, Field 4)

Address Line address, as defined by Max70Text May map to Sixth and Seventh IAT
9.1.11 ++++++ [0..7] O
<AdrLine> postal services, that is Addenda in lieu of separate address fields
text
52 | P a g e

Index Field
Creditor Account Information
Unambiguous
account of the creditor
Creditor Account to which a credit entry
2.80 +++ will be posted as a result
<CdtrAcct>
of the payment
transaction
Empty tag
Unique and
unambiguous
Identification account between the
1.1.0 ++++ [1..1] M
account servicer
Empty tag
International Bank The receiver's bank account number. If the
Account Number (IBAN) account number is less than 35 characters,
For IAT, Entry Detail Record,
- identifier used left justify, blank fill. (Alternate, could be
1.1.1 IBAN IBANIdentifier Foreign Receiver's Account
+++++ internationally by [1..1] M <Other><Identification>)
{OR <IBAN> Number/DFI Account
Number (Record 6, Field 8)
uniquely identify the Usage Rule: If <Othr> is populated,
account of a customer <IBAN > should not be populated
1.1.2 Other by the account servicer,
+++++ using an identification [1..1] M
OR} <Othr>
scheme
Empty tag
53 | P a g e

Index Field
Entry Detail Record, DFI 1. The receiver's bank account number. If
Account Number (Record the account number exceeds 17
Unique and 6, Field 5) positions, only use the left most 17
Identification unambiguous 2. For IAT, Entry Detail characters with spaces omitted and field
1.1.3 ++++++ [1..1] Max35Text M
<Id> identification of a person Record, Foreign left justified
Receiver's Account 2. If the account is less than 35 characters,
Number/DFI Account left justify, blank fill (Alternate, could be
Number (Record 6, Field IBAN, see above)
8)
Nature, or use, of the
Type account
1.1.8 ++++ [0..1] O
<Tp>
Empty tag
Two-digit code that identifies checking and

Name of the Type in a For ALL, Entry Detail savings account credits/debits or prenotes.
1.1.9 Code
+++++ coded form as published [1..1] Code M Record, Transaction Code
(OR <Cd>
in an external list (Record 6, Field 2) Note set to:
"CACC" = Current Account
"SVGS" = Savings Account
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
Underlying reason for the

payment transaction,
e.g., a charity payment,
Purpose or a commercial
2.86 +++ [0..1] O
<Purp> agreement between the
creditor and the debtor
Empty tag
54 | P a g e

Index Field
Options for Outbound Payments:
"ANNI" set to ANN - Annuity
"COMC" set to BUS - Business / Commercial
Specifies the underlying
"DEPT" set to DEP - Deposit
reason for the payment
For IAT, First IAT Addenda "LOAN" set to LOA - Loan
2.87 Code transaction, as published
++++ [1..1] Code M Record, Transaction Type "OTHR" set to MIS - Miscellaneous
{OR <Cd> in an external purpose
Code (Record 7, Field 3) "HLRP" set to MOR - Mortgage
code list
"PENS" set to PEN - Pension
"RENT" set to RLS- Rent
"SALA" set to SLS- Salary
"TAXS" set to TAX - Taxes
2.88 Proprietary Usage Rule: If <Cd> is populated, <Prtry>
++++ purpose [1..1] Max35Text M
Remittance Information Usage Rule: Optional field, either instance of ‘Structured’ or instance of ‘Unstructured’ should be used
Information that enables
the matching, i.e.,
reconciliation, of a 1. For CCD and PPD, Entry
payment with the items Detail Record, Addenda
that the payment is Record Indicator (Record
If present, set Addenda Record Indicator to
Remittance intended to settle, e.g., 6, Field 10)
2.98 +++ [0..1] O “1” (Look for <Structured> or
Information <RmtInf> commercial invoices in 2. For CTX and IAT, Entry
<Unstructured>)
an account receivable Detail Record, Addenda
system Record Indicator (Record
6, Field 12)
Empty tag
For CCD & PPD only one occurrence is

Free text provided for For ALL, Addenda Record /
allowed. Must contain NACHA endorsed
Unstructured information purposes. Max140Text Payment Related
2.99 ++++ [0..n] O ANSI ASC X12 data segments, or NACHA
<Ustrd> Only one occurrence of Information (Record 7,
banking conventions. For IAT two
Unstructured is allowed Field 3)
occurrence is permitted.
55 | P a g e

Index Field
Information supplied to
enable the matching of
an entry with the items
that the transfer is
intended to settle, e.g.,
Structured
2.100 ++++ commercial invoices in [0..n] O
<Strd>
an accounts' receivable
system in a structured
form
Empty tag
Reference information to
allow the identification
Referred Document
of the underlying [0..n]
2.101 Information +++++ O
reference documents
<RfrdDocInf>
Empty tag
For CTX, Addenda Record,
Provides the type of the [0..1] Payment Related
2.102 Type <Tp> ++++++ O
referred document Information (Record 7,
Field 3)
Provides the type details
Code or Proprietary [1..1]
2.103 +++++++ of the referred M
<CdOrPrtry>
document
For CTX, Addenda Record, Presence implies equivalent to STP 820
Code +++++++ Document type in a [1..1] Code Payment Related RMR01 Segment (Reference Identification
2.104 M
<Cd> + coded form Information (Record 7, Qualifier)
Field 3)
Proprietary
Proprietary identification
+++++++ [1..1] Max35Text Usage Rule: If <Cd> is populated, <Prtry>
2.105 of the type of the M
<Prtry> + should not be populated
remittance document
Issuer
Identification of the
[0..1] Max35Text
2.106 +++++++ issuer of the reference O
<Issr>
document type
56 | P a g e

Index Field
Unique and
unambiguous For CTX, Addenda Record,
Equivalent to STP 820 RMR02 Segment
Number identification number of [0..1] Max35Text Payment Related
2.107 ++++++ O (Reference Identification e.g., Invoice
<Nb> the referred document Information (Record 7,
Number)
e.g., invoice or credit Field 3)
note number
Related Date Date associated with the
[0..1] ISODate Payment Related Equivalent to STP 820 Segment DTM02
2.108 <RltdDt> ++++++ referred document, e.g., O
Information (Record 7, (Date)
date of issue
Field 3)
Amount of money and
currency of a document
referred to in the
remittance section. The
Referred Document amount is typically either
Amount the original amount due [0..1]
2.109 +++++ Amount O
<RfrdDocAmt> and payable, or the
amount actually
remitted for the referred
document
Empty tag
Due Payable For CTX, Addenda Record,
Amount specified is the
Amount [0..1] Payment Related Equivalent to STP 820 RMR05 Segment
2.110 ++++++ exact amount due and Amount O
<DuePyblAmt Ccy> Information (Record 7, (Monetary Amount – Invoice Amount)
payable to the creditor
Field 3)
Amount of money
Discount Applied
resulting from the For CTX, Addenda Record,
Amount
application of an [0..1] Payment Related Equivalent to STP 820 RMR06 Segment
2.111 <DscntApldAmt ++++++ Amount O
agreed discount to the Information (Record 7, (Monetary Amount – Adjustment Amount)
Ccy>
amount due and Field 3)
payable to the creditor
Credit Note Amount Amount specified for the
[0..1]
2.112 <CdtNoteAmt Ccy> ++++++ referred document is the Amount O
amount of a credit not
Tax Amount Quantity of cash
2.113 [0..1]
<TaxAmt Ccy > ++++++ resulting from the Amount O
calculation of the tax
57 | P a g e

Index Field
Set of elements used to
Adjustment Amount provide information on
And Reason the amount and reason
[0..n]
2.114 <AdjstmntAmtAndRsn> ++++++ of the document O
adjustment
Empty tag
Amount Amount of money of the
[1..1] Payment Related Equivalent to STP 820 ADX01 Segment
2.115 <Amt Ccy > +++++++ document adjustment Amount M
Information (Record 7, (Monetary Amount – Adjustment Amount)
Field 3)
Specifies whether the For CTX, Addenda Record,
Credit Debit
adjustment must be [0..1] Payment Related Include as part of ADX01 Segment to
2.116 Indicator +++++++ Code O
substracted or added to Information (Record 7, indicate a debit or credit adjustment
<CdtDbtInd>
the total amount Field 3)
Reason Specifies the reason for {0..1] Max4Text Payment Related Equivalent to STP 820 ADX02 Segment
2.117 +++++++ O
<Rsn> the adjustment Information (Record 7, (Adjustment Reason Code)
Field 3)
Additional Provides further details Equivalent to STP 820 ADX03 and ADX04
[0..1] Max140Text Payment Related
2.118 Information +++++++ on the document O Segments (Reference Identification
Information (Record 7,
<AddtlInf> adjustment Qualifier and Reference Identification )
Field 3)
Amount of money
Remitted Amount [0..1] Payment Related Equivalent to STP 820 RMR04 Segment
2.119 ++++++ remitted for the referred Amount O
<RmtdAmt Ccy > Information (Record 7, (Monetary Amount – Amount Paid)
document
Field 3)
Reference information
provided by the creditor
Creditor Reference to allow the
[0..1]
2.120 Information +++++ identification of the O
<CdtrRefInf> underlying documents
Empty tag
58 | P a g e

Index Field
Provides the type of the
Type creditor reference [0..1]
2.121 ++++++ O
<Tp>
Empty tag
Coded or proprietary
format creditor
Code Or Proprietary [1..1]
2.122 +++++++ reference type M
<CdOrPrtry>
Empty tag
For CTX, Addenda Record, Equivalent to STP 820 REF01 Segment
Code +++++++ Coded creditor [1..1] Payment Related (Reference Identification Qualifier e.g.,
2.1223 Code M
<Cd> + reference type Information (Record 7, Purchase Order)
Field 3)
Proprietary Creditor reference type
+++++++ [1..1] Max35Text Usage Rule: If <Cd> is populated, <Prtry>
2.124 <Prtry> not available in a coded M
+ should not be populated
format
Issuer Identification of the
[0..1] Max35Text
2.125 <Issr> +++++++ issuer of the credit O
reference type
Unique and
unambiguous reference
Reference [0..1] Max35Text Payment Related Equivalent to STP 820 Segment REF02
2.126 ++++++ assigned by the creditor O
<Ref> Information (Record 7, (Reference Identification)
to refer to the payment
Field 3)
transaction
organization issuing the
invoice when different
Invoicer [0..1] Payment Related Presence implies STP 820 Segment N101 –
2.127 +++++ from the creditor or O
<Invcr> Information (Record 7, equivalent to “PE”=Payee
ultimate creditor
Field 3)
Empty tag
Name by which a party For CTX, Addenda Record,
Name is known and which is Max140Text Payment Related Equivalent to STP 820 Segment N102 (Payee
9.1.0 ++++++ [0..1] O
<Nm> usually used to identify Information (Record 7, Name)
that party Field 3)
59 | P a g e

Index Field
party to whom an
invoice is issued, when
Invoicee [0..1] Payment Related Presence implies STP 820 Segment N101
2.128 +++++ different from the debtor O
<Invcee> Information (Record 7, equivalent to “PR”=Payer
or ultimate debtor
Field 3)
Empty tag
Name by which a party For CTX, Addenda Record,
Name is known and which is Max140Text Payment Related Equivalent to STP 820 Segment N102 (Payer
9.1.0 ++++++ [0..1] O
<Nm> usually used to identify Information (Record 7, Name)
that party Field 3)
Unique and
unambiguous way of
Identification identifying an
[0..1]
9.1.12 <Id> ++++++ organisation or an O
individual person
Empty tag
Unique an unambiguous
Organisation
way of identifying an
9.1.13 Identification [1..1]
+++++++ organization M
{OR <OrgId>
Empty tag
Code allocated to
9362 Registration
Authority, under an
international
BIC Or BEI +++++++ identification scheme, as
[0..1] Identifier Usage Rule: If <Othr> is populated,
9.1.1.4 <BICOrBEI> + described in the latest O
<BICOrBEI> should not be populated
ISO 9362 Banking
(Banking tele-
communication
Codes)
60 | P a g e

Index Field
an organisation, as
Other +++++++ assigned by an
[0..n]
9.1.15 <Othr> + institution, using an O
Empty tag
Identification +++++++ Identification assigned Equivalent to STP 820 Segment N104
[1..1] Max35Text Payment Related
9.1.16 <Id> ++ by an institution M (Identification Code e.g., Customer
Information (Record 7,
Account Number)
Field 3)
Name of the
+++++++
Scheme Name identification scheme [0..1]
9.1.17 ++ O
<SchmeNm>
Empty tag
Name of the
Code +++++++ identification scheme, in
9.1.18 [1..1] Code Payment Related Equivalent to STP 820 Segment N103 (Payer
<Cd> +++ a coded form as O
{OR Information (Record 7, Identification Code Qualifier)
Field 3)
list
+++++++ Name of the
9.1.19 Proprietary [1..1] Usage Rule: If <Cd> is populated, <Prtry>
+++ identification scheme, in Max35Text M
a free text form
Unique and
Private Identification
9.1.21 unambiguous [1..1] Usage Rule: If <OrgId> is populated,
<PrvtId> +++++++ M
OR} identification of a party <PrvtId > should not be populated
Additional information, in
Additional For CTX, Addenda Record,
free text form, to
Remittance [0..3] Max140Text Payment Related Equivalent to STP 820 Segment REF03
2.129 +++++ complement the O
Information Information (Record 7, (Description)
structured remittance
<AddtlRmtInf> Field 3)
information
61 | P a g e
3. NACHA File Mapping Details
The tables that follow summarize the NACHA file format mappings of relevant PAIN.001 fields.
a. File Header Record – All Formats

The File Header Record introduces the file. It designates the physical file characteristic and identifies the sender of the
file (the ODFI or Gateway Operator for an IAT file) and the party to which the file is being delivered (the ACH
Operator). This record also includes the date, time, and file identification fields that can be used to identify a particular
file.
NACHA File Format Length Position M,R,O Content Description ISO 20022 Mapping Comments
File Header Record (1)
Code identifying the File Header Record is

1 Record Type Code 1 01-01 M Not mapped, set by ODFI system to "1"
"1"
2 Priority Code 2 02-03 R Currently only ”01” is used Not mapped, set by ODFI system to “01”
Maps to 9 digits of ABA and add a blank space
Bank transit routing number preceded by a <PaymentInformation><DebtorAgent>
3 Immediate Destination 10 04-13 M
blank space <FinancialInstitutionIdentification>
<ClearingSystemMemberIdentification><MemberIdentification>
Maps to <GroupHeader><InitiatingParty><Identification>
<OrganisationIdentification><Other><Identification>
10-digit company number assigned by
4 Immediate Origin 10 14-23 M bank typically 9-digit tax ID preceded by Note <SchemeName><Code> also set. Examples:
"1" “TXID” for Tax Identification Number
Maps to <GroupHeader><CreationDateTime>. Creation Date
The date the file was created or
5 File Creation Date 6 24-29 M Time must be split from aggregate ISO data element into File
transmitted
Creation Date and File Creation Time fields respectively
Maps to <GroupHeader><CreationDateTime>
Time of day the file was created or Creation Date Time must be split from aggregate ISO data
6 File Creation Time 4 30-33 O
transmitted element into File Creation Date and File Creation Time fields
respectively
Code to distinguish among multiple input
7 File ID Modifier 1 34-34 M files sent per day. Label the first "A" (or "0") Not mapped, set by ODFI system
and continue in sequence
8 Record Size 3 35-37 M Number of bytes per record, always “94” Not mapped, set to "094" by ODFI system
62 | P a g e
9 Blocking Factor 2 38-39 M Number of records per block Not mapped, set to “10” by ODFI system
10 Format Code 1 40-40 M Must contain “1” Not mapped, set to "1" by ODFI system
Immediate Destination Identifies the bank processing the Maps to <PaymentInformation><DebtorAgent>
11 23 41-63 O
Name transaction e.g., BEST BANK <FinancialInstitutionIdentification><Name>
Company's name, up to 23 characters
12 Immediate Origin Name 23 64-86 O Maps to <GroupHeader><InitiatingParty><Name>
including spaces
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
2Usage may vary with field populated based on bank specific criteria
63 | P a g e
b. Company/Batch Header Record – All SECs Except IAT
A batch is a collection of like entries within the file. A separate batch must be used if any of the batch-level
information, such as effective date or company name or company description changes.
Company/Batch Header Record (5)
Code identifying the Batch Header

Record is "5"
Not mapped2, set to:
“200” for a mixed batch i.e., containing debit and/or credit
Identifies the type of entries in the batch
entries
“200” = mixed debits and credits
2 Service Class Code 3 02-04 M "220" for pain.001 credit transactions only
“220” = credits only
"225" for pain.008 debit transactions only
“225” = debits only
Note <PaymentMethod> also set to "TRF for Credit Transactions
Maps to <PaymentInformation><Debtor><Name>or
Originating company name that has the
3 Company Name 16 05-20 M For 3rd party payment (payment on behalf of), maps to
relationship with the receiver
<CreditTransferTransactionInformation><UltimateDebtor>
<Name>
Company Discretionary
4 20 21-40 O May be used for company's internal use Not mapped*2
Data
Maps to <PaymentInformation><Debtor><Identification>
<OrganizationIdentification><Other<Identification>
5 Company Identification 10 41-50 M 10-digit ID assigned by the bank Note <SchemeName><Code> also set. Examples:
May map to3 <PaymentInformation> level or
<CreditTransferTransactionInformation> level…
<PaymentTypeInformation><LocalInstrument><Code>
Field defines the type of ACH entries Value set to:

6 Standard Entry Class Code 3 51-53 M
contained in the batch "PPD" for PPD/PPD+
"CCD" for CCD/CCD+
"CTX" for Corporate Trade Exchange
Note <ServiceLevel><Code> also set to "NURG"

Field used by the originator to describe
<CreditTransferTransactionInformation>
7 Company Entry Description 10 54-63 M the transaction for the receiver e.g.
level...<PaymentTypeInformation><CategoryPurpose>
PAYROLL or TRADE PAY
<Proprietary>
64 | P a g e
Note preferable to avoid <Proprietary> and use applicable
<Code> from External Code List if possible
Description chosen by the originator to
8 Company Descriptive Date 6 64-69 O Not mapped*
identify the date for the receiver
The date on which the originator intends
9 Effective Entry Date 6 70-75 R Maps to <PaymentInformation><RequestedExecutionDate>
to post to the receiver's account
Inserted
The ACH Operator populates the actual
10 Settlement Date 3 76-78 by ACH Insert 3 blanks2
settlement date
Operator
Identifies the Originator as a non-Federal Not mapped, set to "1" for non-Federal Government entity
11 Originator Status Code 1 79-79 M
Government entity based on client on-boarding process
Maps to first 8 digits of ABA Number
Originating DFI ABA or transit routing <PaymentInformation><DebtorAgent>
12 Originating DFI Identification 8 80-87 M
number assigned <FinancialInstitutionIdentification>
Maps to
<PaymentInformation><PaymentInformationIdentification>
Originator assigns batch numbers in
13 Batch Number 7 88-94 M
ascending order within each file
Else, set by ODFI system2
NOTE:
3 Can be set at the Payment Information level or the Credit Transfer Transaction level. It is possible to have multiple Payment Information blocks, but they must share the
same batch information e.g., Debtor (Company), Debtor Account (Company bank account), Debtor Agent (Company bank), as well as the Requested Execution
Date. However Payment Type Information (e.g., SEC Code, Company Entry Description) cannot be used in both levels.
65 | P a g e
c. Company/Batch Header Record – IAT Only (Outbound Payments)
The Company/Batch Header Record identifies the Originator and briefly describes the purpose of the entry. Note that
the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
IAT Length Position M,R,O Content Description ISO 20022 Mapping Comments
Code identifying the Batch Header

1 Record Type Code 1 01-01 M Not mapped, set by ODFI system to “5”
Record is "5"
Not mapped2, set to:
entries
2 Service Class Code 3 02-04 M "220" for pain.001 credit transactions only
Note <PaymentMethod> also set to "TRF for Credit Transactions
For forward IAT entries, this field should be
3 IAT Indicator 16 05-20 O Not mapped, set to blank for IAT payments
left blank
Code used to indicate the foreign
Generally not mapped2, set to “FF”
exchange conversion methodology
May map to:
applied to an IAT. Code values for this
Set to “FF”- If <CreditTransferTransactionInformation><Amount>
4 Foreign Exchange Indicator 2 21-22 M field are:
<InstructedAmount Currency> present
“FV” Fixed-to-Variable
Set to “FV” - If <CreditTransferTransactionInformation><Amount>
“VF” Variable-to-Fixed
<EquivalentAmount><AmountCurrency> present
“FF” Fixed-to-Fixed
Generally not mapped2, set to “3”
Code used to indicate the type of data in
May map to:
Foreign Exchange Reference Field. Code
Set to “1” - If <CreditTransferTransactionInformation>
values for this field are:
Foreign Exchange <ExchangeRateInformation><ExchangeRate> present
5 1 23-23 R “1” - Foreign Exchange Rate
Reference Indicator Set to “2” - If <CreditTransferTransactionInformation>
“2” - Foreign Exchange Reference
<ExchangeRateInformation><ContractIdentification> present
Number
Set to “3” - If neither <ExchangeRate> nor
“3” - Space Filled
<ContractIdentification> are present
May map to:
<CreditTransferTransactionInformation>
<ExchangeRateInformation><ExchangeRate>
Foreign exchange rate or reference Else <CreditTransferTransactionInformation>
number, as specified in the foreign <ExchangeRateInformation><ContractIdentification>
Foreign Exchange
6 15 24-38 R exchange reference indicator field. If the Else left blank
Reference
foreign exchange reference indicator is 3,
leave this field blank Note If Code AGRD (Exchange rate applied is the rate agreed
with the bank) is used for <Rate Type> then a valid contract
number must be filled
66 | P a g e
Other values for <Rate Type>:
"SALE" = market rate at the time of the sale
"SPOT” = spot rate
This field contains the two-character

code as approved by the International Maps to
ISO Destination Country
7 2 39-40 M Organization for Standardization (ISO) <CreditTransferTransactionInformation><CreditorAgent>
Code
used to identify the country in which the <FinancialInstitutionIdentification><PostalAddress><Country>
entry is to be received
<OrganisationIdentification<Other><Identification>
10-digit ID assigned by the bank, typically
8 Originator Identification 10 41-50 M the IRS Taxpayer Identification Number Note <SchemeName><Code> also set. Examples:
(TIN) of the Originator for U.S. entities “TXID” for Tax Identification Number
<CreditTransferTransactionInformation> level
Field defines the type of ACH entries ...<PaymentTypeInformation><LocalInstrument> <Code> value
9 Standard Entry Class Code 3 51-53 M
contained in the batch set "IAT" for International ACH Transactions
Note <ServiceLevel><Code> also set to "NURG"

CreditTransferTransactionInformation> level
Field used by the originator to describe
...<PaymentTypeInformation> <CategoryPurpose><Proprietary>
10 Company Entry Description 10 54-63 M the transaction for the receiver e.g.
TRADE PAY
Note preferable to avoid <Proprietary> and use applicable
<Code> from External Code List if possible
This field contains the three-character
code as approved by the International
ISO Originating Currency Organization for Standardization (ISO) Maps to <PaymentInformation><DebtorAccount><Currency>
11 3 64-66 M
Code (Account Currency) used to identify the currency e.g., "USD"
denomination in which the entry was first
originated
May map to <CreditTransferTransactionInformation><Amount>
<InstructedAmount>
This field contains the three-character
e.g., <InstdAmtCcy="EUR">1000.00</InstdAmt>
code as approved by the International
Else maps to <CreditTransferTransactionInformation><Amount>
ISO Destination Currency Organization for Standardization (ISO)
12 3 67-69 M <EquivalentAmount><CurrencyofTransfer>
Code (Payment Currency) used to identify the currency
e.g., <EqvtAmt>
denomination in which the entry will be
ultimately settled
<CcyOfTrf>EUR</CcyOfTrf>
</EqvtAmt>
Inserted
The ACH Operator populates the actual
14 Settlement Date (Julian) 3 76-78 by ACH Not mapped. ODFI system generated - insert 3 blanks2
settlement date
Operator
Identifies the Originator as a non-Federal Not mapped, set to "1" for non-Federal Government entity
15 Originator Status Code 1 79-79 M
Government entity based on on-boarding process
67 | P a g e
<PaymentInformation><DebtorAgent>
<FinancialInstitutionIdentification>
Originating DFI ABA or transit routing
16 Originating DFI Identification 8 80-87 M <ClearingSystemMemberIdentification><MemberIdentification>
number assigned
Note <ClearingSystemMemberIdentifciation><Code> also set to
"USABA"
Maps to
Originator assigns batch numbers in <PaymentInformation><PaymentInformationIdentification>
17 Batch Number 7 88-94 M
ascending order within each file
NOTE:
3 Can be set at the Payment Information level or the Credit Transfer Transaction level. It is possible to have multiple Payment Information blocks, but they must share the
same batch information e.g., Debtor (Company), Debtor Account (Company bank account), Debtor Agent (Company bank), as well as the Requested Execution
Date. However Payment Type Information (e.g., SEC Code, Company Entry Description) cannot be used in both levels.
68 | P a g e
d. CCD or PPD Entry Detail Record
The CCD Entry Detail Records contain information about the Receiver and the Receiver's financial institution.
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"
Maps to
<CreditTransferTransactionInformation><CreditorAccount>
Two-digit code that identifies the type of
<Type><Code>
2 Transaction Code 2 02-03 M entry: checking and savings account
credits/debits or prenotes
Maps to first 8 digits:
<CreditTransferTransactionInformation><CreditorAgent>
First 8 digits of the receiver's bank transit
3 Receiving DFI Identification 8 04-11 M <FinancialInstitutionIdentification>
routing number
<ClearingSystemMemberIdentification>
<MemberIdentification>
Maps to 9th digit:
Last digit of the receiver's transit bank <ClearingSystemMemberIdentification>
4 Check Digit 1 12-12 M
routing number <MemberIdentification>
Note that Field 3 and 4 are combined for Record 6 as the

Check Digit is the last (or 9th) digit of the transit routing number
The receiver's bank account number. If the
Maps to
account number exceeds 17 positions, only
5 DFI Account Number 17 13-29 R <CreditTransferTransactionInformation><CreditorAccount>
use the left most 17 characters with spaces
<Identification><Other><Identification>
omitted and field left justified
The amount of the transaction in dollars
Maps to <CreditTransferTransactionInformation><Amount>
6 Amount 10 30-39 M with two decimal places. Right justified, left
<InstructedAmount>
zero-filled without a decimal point
Identification Number field may be used by
Maps to <CreditTransferTransactionInformation>
7 Identification Number 15 40-54 O the Originator to insert its own number for
<PaymentIdentification><EndtoEndIdentification>
tracing purpose
Maps to <CreditTransferTransactionInformation><Creditor>
<Name>
8 Receiving Company Name 22 55-76 R Name of Receiver
For 3rd party payment (ultimate receiver of payment), maps to
<UltimateCreditor> <Name>
Field defined by the ODFI some banks
9 Discretionary Data 2 77-78 O Not mapped*2
request it be left blank
69 | P a g e
[NOTE: As content varies by client and on-boarding process2
requirements for mapping may differ as well.]
”0” = no addenda record supplied
10 Addenda Record Indicator 1 79-79 M Set Addenda Record Indicator to “1” if element
”1” = one addenda record supplied
<RemittanceInformation><Unstructured> or <Structured>
present
Means for the originator to identify the

individual entries. Field is constructed as
follows: the first 8 digits are the ODFI transit
Not mapped, generated by ODFI system: set first 8 digits to
11 Trace Number 15 80-94 M routing number or Field 12 of the
ODFI transit routing number followed by sequential number
Company/Batch Header. The remainder
must be a unique number in sequential
order
NOTE:
70 | P a g e
e. CTX Entry Detail Record
The CTX Entry Detail Records contain information about the Receiver and the Receiver's financial institution.
CTX Length Position M,R,O Content Description ISO 20022 Mapping Comments

1 Record Type Code 1 01-01 M Not mapped set by ODFI system to “6”
"6"
Maps to
Two-digit code that identifies checking
<Type><Code>
2 Transaction Code 2 02-03 M and savings account credits/debits or
prenotes.
First 8 digits of the receiver's bank transit <CreditTransferTransactionInformation><CreditorAgent>
3 Receiving DFI Identification 8 04-11 M
routing number of the <FinancialInstitutionIdentification>
Maps to 9th digit:
Last digit of the receiver's transit bank
4 Check Digit 1 12-12 M <ClearingSystemMemberIdentification><MemberIdentification>
routing number
Note that Field 3 and 4 are combined for Record 6 as the Check
Digit is the last (or 9th) digit of the transit routing number
The receiver's bank account number. If
the account number exceeds 17 Maps to
5 DFI Account Number 17 13-29 R positions, only use the left most 17 <CreditTransferTransactionInformation><CreditorAccount>
characters with spaces omitted and field <Identification><Other><Identification>
left justified
6 Amount 10 30-39 M with two decimal places. Right justified,
<InstructedAmount>
left zero-file without a decimal point
Identifying (e.g., accounting) number by
7 Identification Number 15 40-54 O which the receiver is known to the
<PaymentIdentification><EndtoEndIdentification>
originator for descriptive purposes
The number of addenda records
Number of Addenda
8 4 55-58 M associated with the CTX Entry Detail Not mapped, calculated by ODFI system
Records
Record
Maps to
<CreditTransferTransactionInformation><Creditor><Name>
9 Receiving Company Name 16 59-74 R Name of Receiver
For 3rd party payment (ultimate beneficiary of payment), maps
to <UltimateCreditor> <Name>
71 | P a g e
10 Reserved 2 75-76 N/A Leave blank Not mapped*
Field defined by the ODFI some banks
11 Discretionary Data 2 77-78 O Not mapped*2
request it be left blank
[NOTE: As content varies by client and on-boarding process2
requirements for mapping may differ as well.]
“0” = no addenda record supplied
12 Addenda Record Indicator 1 79-79 M ”1” = one or more addenda records
Set Addenda Record Indicator to “1” if element
supplied
<RemittanceInformation><Unstructured> or <Structured>
present
Not mapped, generated by ODFI system: set first 8 digits to ODFI
transit routing number followed by sequential number
positions must be a unique number in
sequential order
NOTE:
72 | P a g e
f. IAT Entry Detail Record (Outbound Payments)
The IAT Entry Detail Records contain information about the Receiver and the Receiver's financial institution. IAT is a bi-
directional transaction. Note that the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S.
to a foreign country.

"6"
Maps to
Two-digit code that identifies the type of
<Type><Code>
2 Transaction Code 2 02-03 M entry: checking and savings account
credits/debits or prenotes
<CreditTransferTransactionInformation><IntermediaryAgent1>
Gateway Operator (GO) Routing number of the U.S. Gateway
3 8 04-11 M <ClearingSystemMemberIdentification><MemberIdentification>
Identification Operator
Note <ClearingSystemMemberIdentifciation><Code> also set to
"USABA"
Maps to 9th digit:
<CreditTransferTransactionInformation><IntermediaryAgent1>
Last digit of the receiver's transit bank <FinancialInstitutionIdentification><MemberIdentification>
4 Check Digit 1 12-12 M
routing number
Note that Field 3 and 4 are combined for Record 6 as the Check
Digit is the last (or 9th) digit of the transit routing number
The number of addenda records

Number of Addenda
5 4 13-16 M associated with the IAT Entry Detail Not mapped, calculated by ODFI system
Records
Record
6 Reserved 13 17-29 N/A Leave blank Not mapped*, leave blank

7 Amount 10 30-39 M with two decimal places. Right justified,
<InstructedAmount>
left zero-file without a decimal point
Maps to
Foreign Receiver's Account
8 35 40-74 M Receiver's account number <CreditTransferTransactionInformation><CreditorAccount>
Number
<Identification><IBAN> (e.g., SEPA region)
73 | P a g e
Else <CreditTransferTransactionInformation><CreditorAccount>
<Identification> <Other><Identification>
9 Reserved 2 75-76 N/A Leave blank Not mapped* , leave blank

This field indicates the results of a
Gateway Operator screen for OFAC
compliance.
Gateway Operator (GO) “0” = Gateway Operator has not found a Not mapped, leave blank. To be filled by the Gateway
10 1 77-77 O
OFAC Screening Indicator potential blocked party Operator
“1” = presence of a blocked party
This field must be space filled if no
screening has been conducted
This field indicates the results of a Third-
Party Service Provider screen for OFAC
compliance.
“0” = Third-Party Service Provider has not
Secondary OFAC Screening
11 1 78-78 O found a potential blocked party Not mapped, leave blank
Indicator
“1” =the potential presence of a blocked
party
This field must be space filled if no
screening has been conducted
“0” = no addenda record supplied
12 Addenda Record Indicator 1 79-79 M Always set to “1”
“1” = one addenda record supplied
Not mapped, generated by ODFI system: set first 8 digits to ODFI
transit routing number followed by sequential number
positions must be a unique number in
sequential order
NOTE:
74 | P a g e
g. CCD Addenda Record (Optional)
CCD entries will accommodate the transmission of optional remittance information.
CCD Length Position M,R,O Content Description ISO 20022 Mapping Comments
CCD Addenda Record (7) NOTE: A maximum of 1 optional addenda record may be included with each CCD entry
Code identifying the Addenda Record

1 Record Type Code 1 01-01 M Not mapped, set to "7" by ODFI system to “7”
type is "7"
Not mapped, set to by ODFI system "05" for CCD addenda
2 Addenda Type Code 2 02-03 M Code identifying the Addenda type
record
[NOTE: Content varies by client and on-boarding process2]
Remittance information associated with
the preceding Entry Detail Record. Must May map to <RemittanceInformation><Unstructured> or
Payment Related
3 80 04-83 O contain NACHA endorsed ANSI ASC X12 <Structured>
Information
data segments or NACHA banking
convention Please refer to the Remittance section of this document for
limited EDI ANSI X12 mapping
Sequence number of each addenda
Addenda Sequence Not mapped, system generated, set in ascending order
4 4 84-87 M record in ascending order beginning with
Number beginning with 0001
0001
This field contains the ascending sequence
number section of the Entry Detail or
Entry Detail Sequence Corporate Entry Detail Record‘s trace Not mapped, system generated from last 7 digits of Trace
5 7 88-94 M
Number number. This number is the same as the last Number
seven digits of the trace number (Field 11)
of the related Entry Detail Record
NOTE:
75 | P a g e
h. CTX Addenda Record (Optional)
CTX entries will accommodate the transmission of optional remittance information.
CTX Length Position M,R,O Content Description ISO 20022 Mapping Comments
CTX Addenda Record (7) NOTE: A maximum of 9,999 optional addenda records may be included with each CTX entry

type is "7"
Not mapped, set " by ODFI system to "05" for CTX addenda
2 Addenda Type Code 2 02-03 M Code identifying the Addenda type
records
[NOTE: Content varies by client and on-boarding process2]
Remittance information associated with
May map to <RemittanceInformation><Unstructured> or
the preceding Entry Detail Record. Must
Payment Related <Structured>
3 80 04-83 O contain NACHA endorsed ANSI ASC X12
Information
data segments, NACHA banking
Please refer to the Remittance section of this document for
conventions or XML
equivalent STP 820 data segments or limited EDI ANSI X12
mapping
Sequence number of each addenda
4 4 84-87 M record in ascending order beginning with
0001
This field contains the ascending
sequence number section of the Entry
Detail or Corporate Entry Detail Record‘s
Entry Detail Sequence Not mapped, system generated from last 7 digits of Trace
5 7 88-94 M trace number. This number is the same as
Number Number
the last seven digits of the trace number
(Field 13) of the related Entry Detail
Record
NOTE:
76 | P a g e
i. IAT First Addenda Record (710) (Outbound Payments)
The First IAT Addenda Record identifies the Receiver of the transaction and the dollar amount of the payment. Note that
the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
First IAT Addenda Record (7) NOTE: The first seven IAT addenda records are mandatory for each IAT entry

type is "7"
Code identifying the First Addenda
2 Addenda Type Code 2 02-03 M Not mapped, set by ODFI system to "10"
Record
<CreditTransferTransactionInformation><Purpose><Code>
Options for Outbound Payments:

"ANNI" set to ANN - Annuity
"COMC" set to BUS - Business / Commercial
"DEPT" set to DEP - Deposit
A three-character code used to identify "LOAN" set to LOA - Loan
3 Transaction Type Code 3 04-06 R
the type of transaction "OTHR" set to MIS - Miscellaneous
"HLRP" set to MOR - Mortgage
"PENS" set to PEN - Pension
"RENT" set to RLS- Rent
"SALA" set to SLS- Salary
"TAXS" set to TAX - Taxes
The amount for which the entry is to be

Maps to:
received by the foreign receiver in the
<CreditTransferTransactionInformation><Amount>
currency denomination expressed in the
<InstructedAmount Currency> or
4 Foreign Payment Amount 18 07-24 R ISO Destination Currency Code for "VF"
<EquivalentAmount><AmountCurrency>
and "FF" foreign exchange indicators;
For "FV" - zero fill
otherwise this field is zero filled (i.e., for "FV"
For "VF" or “FF” - numerical value
foreign exchange indicator)
The trace number assigned to the entry in
5 Foreign Trace Number 22 25-46 O Not mapped system generated: insert zeros or leave blank
the originating national payments system
Receiving Company This field identifies the Receiver of the Maps to

6 35 47-81 M
Name/Individual Name transaction <CreditTransferTransactionInformation><Creditor><Name>4

Entry Detail Sequence sequence number section of the Entry Not mapped, system generated from last 7 digits of Trace
8 7 88-94 M
Number Detail Record‘s trace number. This number Number
is the same as the last seven digits of the
77 | P a g e
trace number (Field 13) of the related
Entry Detail Record
NOTE:
4For 3rd party payment i.e., payment on behalf of, maps to <UltimateDebtor> fields
78 | P a g e
j. IAT Second Addenda Record (711) (Outbound Payments)
The Second and Third IAT Addenda Records identify key information related to the Originator of the entry. Note that the
mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
Second IAT Addenda Record (7)

type is "7"
Code identifying the Second Addenda
Record
This field contains the name of the
3 Originator Name 35 04-38 M Maps to <PaymentInformation><Debtor><Name>4
Originator of the transaction
This field contains the physical street May map to4 <PaymentInformation><Debtor><PostalAddress>
4 Originator Street Address 35 39-73 M
address of the Originator <StreetName> and <BuildingNumber> or <AddressLine>
Number Number
Record
NOTE:
79 | P a g e
k. IAT Third Addenda Record (712) (Outbound Payments)
Note that the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
Third IAT Addenda Record (7)

type is "7"
Code identifying the Third Addenda
Record
This field contains the city and, if
Originator City & May map to4 <PaymentInformation><Debtor><PostalAddress>
3 35 04-38 M applicable, the state or province of the
State/Province <TownName> and <CountrySubDivision> or <AddressLine>
Originator
Originator Country & Postal This field contains the country and postal May map to4 <PaymentInformation><Debtor><PostalAddress>
4 35 39-73 M
Code code of the Originator <PostCode> and <Country> or <AddressLine>
Number Number
Record
NOTE:
80 | P a g e
l. IAT Fourth Addenda Record (713) (Outbound Payments)
The Fourth IAT Addenda Record contains information related to the financial institution originating the entry. Note that the
Fourth IAT Addenda Record (7)

type is "7"
Code identifying the Fourth Addenda
Record
This field contains the name of the Maps to <PaymentInformation><DebtorAgent>
3 Originating DFI Name 35 04-38 M
Originating DFI <FinancialInstitutionIdentification><Name>
Set to "01" for U.S. clearing system
This field contains a 2-digit code that
Originating DFI <PaymentInformation><DebtorAgent>
identifies the numbering scheme used in
4 Identification Number 2 39-40 M <FinancialInstitutionIdentification>
the Originating DFI Identification Number
Qualifier <ClearingSystemMemberIdentification>
field
<ClearingSystemIdentification><Code> "USABA" is present
Maps to <PaymentInformation><DebtorAgent>
Originating DFI Originating DFI ABA or transit routing
5 34 41-74 M <FinancialInstitutionIdentification>
Identification number
This field contains a 2-character code as
approved by the International Maps to <PaymentInformation><DebtorAgent>
Originating DFI Branch Organization for Standardization (ISO) <FinancialInstitutionIdentification><PostalAddress> <Country>
6 3 75-77 M
Country Code used to identify the country in which the
branch of the bank that originated the "US" is present
entry is located
Number Number
Record
NOTE:
81 | P a g e
m. IAT Fifth Addenda Record (714) (Outbound Payments)
The Fifth IAT Addenda Record identifies the Receiving financial institution holding the Receiver's account. Note that the
Fifth IAT Addenda Record (7)

type is "7"
Code identifying the Fifth Addenda
Record
This field contains the name of the Maps to <CreditTransferTransactionInformation>
3 Receiving DFI Name 35 04-38 M
Receiving Depository Financial Institution <CreditorAgent><FinancialInstitutionIdentification><Name>
Set to:
This field contains a 2-digit code that “01” if <CreditTransferTransactionInformation><CreditorAgent>
identifies the numbering scheme used in <FinancialInstitutionIdentification>
the Receiving DFI Identification Number <ClearingSystemMemberIdentification>
Receiving DFI Identification
4 2 39-40 M field. Code values for this field are: <ClearingSystemIdentification><Code> is present
Number Qualifier
“01”= National Clearing System Number; “02” if <CreditTransferTransactionInformation><CreditorAgent>
“02”= BIC Code; or <FinancialInstitutionIdentification><BIC> is present
“03”= IBAN. “03” if <CreditTransferTransactionInformation>
<CreditorAgentAccount><Identification><IBAN> is present
<CreditorAgent><FinancialInstitutionIdentification>
The Routing Number used to identify the <ClearingSystemMemberIdentification><MemberIdentification>
5 Receiving DFI Identification 34 41-74 M DFI in which the Receiver maintains his Else <CreditTransferTransactionInformation><CreditorAgent>
account <FinancialInstitutionIdentification><BIC> (e.g., SEPA region)
Else <CreditTransferTransactionInformation>
<CreditorAgentAccount><Identification><IBAN>
This field contains a 2-character code as
approved by the International
Maps to
Receiving DFI Branch Organization for Standardization (ISO)
6 3 75-77 M <CreditTransferTransactionInformation><CreditorAgent>
Country Code used to identify the country in which the
<FinancialInstitutionIdentification><PostalAddress><Country>
branch of the bank that receives the entry
is located
Number Number
Record
NOTE: *Field typically not used by U.S. banks
82 | P a g e
n. IAT Sixth Addenda Record (715) (Outbound Payments)
The Sixth and Seventh IAT Addenda Records identify key information related to the Receiver of the entry. Note that the
Sixth IAT Addenda Record (7)

type is "7"
Code identifying the Sixth Addenda
Record
This field contains the accounting number
Receiver Identification Maps to <CreditTransferTransactionInformation>
3 15 04-18 O by which the Originator is known to the
Number <PaymentIdentification><EndtoEndIdentification>
Receiver for descriptive purposes
May map to5 <CreditTransferTransactionInformation><Creditor>
This field contains the physical street
4 Receiver Street Address 35 19-53 M <PostalAddress><StreetName> and <BuildingNumber> or
address of the Receiver
<AddressLine>
Number Number
Record
NOTE:
5For 3rd party payment i.e., ultimate beneficiary of payment, maps to <UltimateCreditor> fields
83 | P a g e
o. IAT Seventh Addenda Record (716) (Outbound Payments)
Note that the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
Seventh IAT Addenda Record (7)

type is "7"
Code identifying the Seventh Addenda
Record
This field contains the city and, if May map to5 <CreditTransferTransactionInformation><Creditor>
Receiver City &
3 35 04-38 M applicable, the state or province of the <PostalAddress><TownName> and <CountrySubDivision> or
State/Province
Receiver <AddressLine>
Receiver Country & Postal This field contains the country and postal May map to5 <CreditTransferTransactionInformation><Creditor>
4 35 39-73 M
Code code of the Receiver <PostalAddress><Country> and <PostCode> or <AddressLine>
Number Number
Record
NOTE:
*Field typically not used by U.S. bank
5For 3rd party payment i.e., ultimate beneficiary of payment, maps to <UltimateCreditor> fields
84 | P a g e
p. IAT Addenda Record for Remittance Information (717) (Optional) (Outbound Payments)
IAT entries will accommodate the transmission of optional remittance information. Note that the mapping provided herein
is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
IAT Addenda For Remittance Information Record (7) NOTE: A maximum of two optional remittance addenda records may be included with each IAT entry

type is "7"
Code identifying the Addenda Record for
Remittance Information
There are no formatting specifications for
the optional remittance information [NOTE: Content varies by client and on-boarding process2]
except for those banking conventions
Payment Related
3 80 04-83 O that have been developed to carry May map to <RemittanceInformation><Unstructured> or
Information
mandatory information for secondary SEC <Structured>
codes identified in the Transaction Type
code field.
Sequence number of each type of "17"
4 4 84-87 M remittance addenda in ascending order
beginning with 0001
Number Number
Record
NOTE:
85 | P a g e
q. IAT Addenda Record for Foreign Correspondent Bank Information (718) (Outbound Payments)
IAT Addenda Records for Foreign Correspondent Bank Information applies to Incoming/Received IAT entries only. Note
that the mapping provided herein is for outbound IAT only i.e., funds are moving from the U.S. to a foreign country.
IAT Addenda For Foreign Correspondent Bank Information Record (7) NOTE: A maximum of three optional Foreign Correspondent Bank addenda records may be included with
each IAT entry
1 Record Type Code 1 01-01 M Code identifying the Addenda Record Not mapped, set by ODFI system to "7"
type is "7"
2 Addenda Type Code 2 02-03 M Code identifying the Addenda Record for Not mapped, set by ODFI system to "18"
Foreign Correspondent Bank Information
for IAT
3 Foreign Correspondent Bank 35 04-38 M This field identifies the name of the Foreign Maps to IntermediaryAgent2><FinancialInstitutionIdentification>
Name Correspondent Bank <Name> or <IntermediaryAgent3>
<FinancialInstitutionIdentification><Name>
4 Foreign Correspondent Bank 2 39-40 M This field contains a 2-digit code that Set to:
Identification Number identifies the numbering scheme used in “01” if
Qualifier the Foreign Correspondent Bank <CreditTransferTransactionInformation><IntermediaryAgent2> or
Identification Number field. Code values <IntermediaryAgent3><FinancialInstitutionIdentification>
for this field are: <ClearingSystemMemberIdentification>
“01” = National Clearing System Number <ClearingSystemIdentification><Code> is present
(e.g., U.S. Routing Transit Number) “02” if
“02” = BIC Code <CreditTransferTransactionInformation><IntermediaryAgent2> or
“03” = IBAN <IntermediaryAgent3> <FinancialInstitutionIdentification><BIC> is
present
“03” if <CreditTransferTransactionInformation>
IntermediaryAgent2Account> or
<IntermediaryAgent3Account><Identification><IBAN> is present
5 Foreign Correspondent Bank 34 41-74 M This field contains bank identification Maps to:
Identification Number number (i.e., the National Clearing System <CreditTransferTransactionInformation><IntermediaryAgent2> or
Number, BIC Code, or IBAN) of the Foreign <IntermediaryAgent3><FinancialInstitutionIdentification>
Correspondent Bank <ClearingSystemMemberIdentification> <MemberIdentification>
Else
<CreditTransferTransactionInformation><IntermediaryAgent2> or
<IntermediaryAgent3> <FinancialInstitutionIdentification><BIC>
Else <CreditTransferTransactionInformation>
<IntermediaryAgent2Account> or
<IntermediaryAgent3Account><Identification><IBAN>
6 Foreign Correspondent Bank 3 75-77 M This field contains a 2-character code as
Branch Country Code approved by the International Maps to
Organization for Standardization (ISO) <CreditTransferTransactionInformation><IntermediaryAgent2> or
used to identify the country in which the <IntermediaryAgent3><FinancialInstitutionIdentification><Postal
branch of the Foreign Correspondent Address><Country>
Bank is located
86 | P a g e
8 Addenda Sequence 4 84-87 M Sequence number of each type of "18" Not mapped, system generated, set in ascending order
Number Foreign Correspondent Bank Identification beginning with 0001
addenda in ascending order beginning
with 0001
9 Entry Detail Sequence 7 88-94 M This field contains the ascending
Number sequence number section of the Entry
Detail or Corporate Entry Detail Record‘s Not mapped, system generated from last 7 digits of Trace
trace number. This number is the same as Number
Record
NOTE:
87 | P a g e
r. Batch/Control Record – All Formats
The Company/Batch Control Record summarizes the information contained within the batch. It contains the counts, hash
totals, and total dollar controls for the entries within the batch.
Batch Control Record (8)
Code identifying the Company / Batch

Header Record is "8"
Not mapped, set to:
2 Service Class Code 3 02-04 M entries
"220" for pain.001 credit transactions only
Total number of Entry Detail Records plus
addenda records (Record Types "6" and Not mapped2, system calculated based on accepted
3 Entry/Addenda Count 6 05-10 M
"7") in the batch. Requires 6 positions, right- transactions
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, system calculated and generated
Detail Record)
Total Debit Entry Dollar
5 12 21-32 M Dollar total of debit entries in the batch Not mapped2, system calculated (may be “0” filled)
Amount in Batch
Total Credit Entry Dollar Not mapped2, system calculated based on accepted
6 12 33-44 M Dollar total of credit entries in the batch
Amount in Batch transactions
<OrganisationIdentification><Other><Identification>
7 Company Identification 10 45-54 R 10-digit ID assigned by the bank Note <SchemeName><Code> also set. Examples:
Message Authentication
8 19 55-73 O Leave blank Not mapped*
Code
9 Reserved 6 74-79 N/A Leave blank Not mapped*2
<PaymentInformation><DebtorAgent>
Originating DFI Originating DFI ABA or transit routing
10 8 80-87 M <FinancialInstitutionIdentification>
Identification number assigned
<ClearingSystemMemberIdentification>
<MemberIdentification>
Maps to
Sequential number assigned by the
<PaymentInformation><PaymentInformationIdentification>
11 Batch Number 7 88-94 M originator. Must be equal to Field 13 of the
Company/Batch Header Record
88 | P a g e
NOTE:
89 | P a g e
s. File Control Record – All Formats
The File Control Record summarizes the information carried in the Company/Batch Control Records. It contains dollar,
entry, and hash total accumulations from the Company/Batch Control Records in the file. This record also contains counts
of the number of blocks and the number of batches within the file.
File Control Record (9)
Code identifying the File Control Record is

"9"
Value must be equal to the number of Not mapped2, system calculated based on accepted
2 Batch Count 6 02-07 M
batch header '5' records in the file transactions
Number of physical blocks in the file,
3 Block Count 6 08-13 M including the file header and file control Not mapped, system calculated and generated
records
Sum of all '6' records and also '7' records, if Not mapped2, system calculated based on accepted
4 Entry/Addenda Count 8 14-21 M
used transactions
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 left Not mapped2, system calculated and generated
most numbers
Total Debit Entry Dollar
6 12 32-43 M Dollar total of debit entries in the file Not mapped2, system calculated (may be “0” filled)
Amount in File
Total Credit Entry Dollar Not mapped2, system calculated based on accepted
7 12 44-55 M Dollar total of credit entries in the file
Amount in File transactions
8 Reserved 39 56-94 N/A Leave blank Not mapped*
NOTE:
* Field typically not used by U.S. banks
90 | P a g e
4. Remittance Information
The content of remittance data varies by the bank client and the on-boarding process. For the CCD Standard Entry Class
Code, the NACHA Operating Rules permit the exchange of endorsed banking conventions or ANSI ASC X12 syntax-based
data segments within the addenda record. In a CTX payment, the NACHA Operating Rules permit the exchange of ANSI ASC
X12 transaction set containing a BPR or BPS data segment, or payment related UN/EDIFACT syntax.
It should be noted that this Guide offers documentation for the future support of CCD ISO 20022-based XML remittance
addenda. Given that state agencies today do not accept XML data, NACHA does not support the transmission of XML
messages for CCD+ at this time. However, this information has been included below in preparation for when markets evolve.
a. CCD Addenda – NACHA Endorsed Banking Conventions for TXP, DED, and TPP Payments
Corporate Credit or Debit Entry (CCD) payments have a limitation of only one 80-character remittance addendum. In
order to transmit remittance information with CCD transactions in XML formatted data, either an unstructured and
structured format may be used. Note that the structured XML tags can utilize most of, if not more than, the 80-characters in
the one addendum. In both scenarios, with structured or unstructured XML formatted data, payments reconciliation and
straight-through processing can still be achieved by following the guidelines provided.
Today, the NACHA Operating Rules allow endorsed banking conventions for “TXP”, “DED”, and “TPP” to accompany a
CCD payment utilizing ANSI ASC X12 standards. The banking conventions define the data and formats for these specific
use cases mostly for government payments:
 TXP – tax payment (used by businesses to pay state revenue authorities)

 DED – child support payment (used by employers/payroll companies to submit payments to child support authorities)
 TPP – third party payment (used by employers/payroll companies to submit wage garnishment for back state taxes)
91 | P a g e
1) Unstructured
In an unstructured form, it is recommended that remittance information transmitted is consistent with the current
practice of NACHA banking conventions that is exchanged today in EDI X12 ANSI format. Of note, the use of all
mandatory and optional fields in the TPP and DED conventions inclusive of the “*” field separators can exceed the 80
character limit in EDI format and within an unstructured XML format. Therefore, it is the responsibility of each user to
ensure the 80-character limit is not exceeded.
The following provide examples of NACHA banking convention remittance addendum in an unstructured XML format:
Figure 7: NACHA Banking Convention – TXP Example
<RmtInf>
<Ustrd>TXP*3710123456*011*061231*t*10199997*P*200000\</Ustrd>
</RmtInf>
Figure 8: NACHA Banking Convention – DED Example
<RmtInf>
<Ustrd>DED*CS*1998-840123-DM*20070613*46252*386863555*Y*Doe,John*26082*N\</Ustrd>
</RmtInf>
Figure 9: NACHA Banking Convention – TPP Example
<RmtInf>
<Ustrd>TPP*208*123456789*20121130*100000*1122*SMITH JOHN*AB123456\</Ustrd>
</RmtInf>
92 | P a g e
As XML formatted data is not accepted market practice, in order to transmit the addenda information to the clearing
system, it is recommended that the ODFI drops the unstructured tags and include the remittance information in the “7”
record of the NACHA file to pass on the data. An illustration is provided below.
Figure 10:
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Example Data
705 TXP*3710123456*011*061231*T*10199997*P*200000\ 00010001610
2) Structured
If the NACHA endorsed banking conventions for DED, TXP, and TPP are transmitted in a structured form in the payment
instruction file to the ODFI, following the guidelines provided below is recommended. Note that the structured data
elements may not all fall within the Remittance Information section in the pain.001 message.
Further, as previously noted, XML formatted data is not accepted market practice for CCD+. In order to transmit the
structured addenda information to the clearing system, it is recommended that the XML tags are dropped, the data
concatenated to follow the current practice of EDI X12 ANSI format exchanged today, and to include the remittance
information in the “7” record of the NACHA file.
Tax Payment – TXP Segment
Tax payments made by businesses to state revenue authorities are supported through the use of the TXP segment in
ACH addenda. The ISO equivalent and mappings for TXP01–TXP10 are provided below for the pain.001 message.
Note that some segments (TXP05, TXP07, and TXP09 as well as TXP04, TXP06, and TXP08) can have multiple occurrences
and may be mapped to the same data element.
93 | P a g e
Table 1: NACHA Endorsed Banking Convention – TXP Mapping to ISO Equivalent*
Segment Data Element Definition ISO Equivalent

Contains the taxpayer’s
identification number as assigned by
Taxpayer Identification <Payment Information><UltimateDebtor><Identification>
TXP01 the taxing authority. This is the nine-
Number <OrganisationIdentification><Other><Identification>
digit Employer Identification Number
(EIN) for Federal tax payments
Tax Payment Type
TXP02 Type of tax being paid <CreditTransferTransactionInformation><Tax><Record><Type>
Code
End date for the tax period for which <CreditTransferTransactionInformation><Tax><Record><Period>
TXP03 Tax Period End Date
the payment is being made <FromToDate><ToDate>
Identifies the type of amount that
immediately follows:
T= Tax
Amount Type (Tax <CreditTransferTransactionInformation><Tax><Record>
TXP04 I= Interest
Information ID Number) <CategoryDetails>
S= State
L= Local
C = City
<CreditTransferTransactionInformation><Tax><Record>
Amount of tax liability owed and/or <TaxAmount><TotalAmountCurrency>
paid. If no subsequent amounts are
reported in data elements TXP07 and Optional to also include here when no other tax amount(s), i.e.,
TXP05 Tax Amount TXP09, the amount value reported in TXP07 and/or TXP09 is present:
TXP05 must equal the value <CreditTransferTransactionInformation><Tax>
contained in Field 6 in the CCD Entry <TotalTaxAmount>
Detail Record [Total of all <Record> level Tax Amounts. Total of the actual tax
payment.]

T= Tax
TXP06 I= Interest
S= State
L= Local
C = City
94 | P a g e
Amount of tax liability owed and/or
paid. This amount value is optional,
but must be used if TXP06 is present. If
no subsequent amount is
TXP07 Tax Amount reported in data element TXP09, the
<TaxAmount><TotalAmountCurrency>
total amount value reported in the
convention (TXP05 +TXP07) must
equal the value contained in Field 6
in the CCD Entry Detail Record
T= Tax
TXP08 I= Interest
S= State
L= Local
C = City
Amount of tax liability owed and/or
paid. This amount value is optional,
but must be used if TXP08 is present.
The total amount value reported in <CreditTransferTransactionInformation><Tax><Record>
TXP09 Tax Amount
the convention (TXP05 <TaxAmount><TotalAmountCurrency>
+TXP07+TXP09) must equal the value
contained in Field 6 in the CCD Entry
Detail Record
Optional data element that may be
<CreditTransferTransactionInformation><Tax><Debtor>
TXP10 Taxpayer Verification used by the receiver to verify the
<TaxIdentification>
taxpayer's identify
*Please refer to ISO 20022 pain.001 file for the paths provided above.
Tax Payment – TPP Segment
Tax payments made by third parties, such as employers to government agencies for delinquent taxpayers are
supported through the use of the TPP segment in the ACH addenda. The ISO equivalent and mappings for TPP01–
TPP07 are provided below for the pain.001 message. Note that TPP03 and TPP07 may be mapped to multiple ISO
equivalent data elements. It is also important to be aware that all data elements do not fall within the Remittance
Information section of the ISO message.
95 | P a g e
Table 2: NACHA Endorsed Banking Convention – TPP Mapping to ISO Equivalent*

Tax Payment <PaymentInformation><PaymentTypeInformation>
TPP01 State assigned tax type
Type Code <CategoryPurpose><Code>
Identifies the third party that originated the
payment. The third party’s identification or <CreditTransferTransactionInformation><<Tax><Debtor>
TPP02 Reference ID
registration number as assigned by the state taxing <TaxIdentification>
authority
2 possible applications:
Date applicable to this payment, may be a payroll
1. Payroll / Account debit date –
date (for wage garnishments) an account debit
<CreditTransferTransactionInformation><Tax><Date>
TPP03 Date date (for
financial institution garnishments) or a tax period
2. Tax period end date –
end date
<Period><FromToDate><ToDate>
Amount of payment, should match the ACH De
TPP04 Amount
tail Record (6 record) amount <CreditTransferTransactionInformation><Tax><TotalTaxAmount>
Identification number of the taxpayer on whose <PaymentInformation><UltimateDebtor><Identification>
TPP05 Reference ID
behalf payment is being made <PrivateIdentification><Other><Identification>
First 13 characters of the taxpayer’s name on w
TPP06 Name
hose behalf payment is being made <PaymentInformation><UltimateDebtor><Name>
2 possible applications:
Optional second identification number of the
1. <CreditTransferTransactionInformation><Tax><Debtor>
taxpayer on whose
<RegistrationIdentification> (e.g., state account
TPP07 Reference ID behalf payment is being made, such as a state
number)
assigned account number or a case reference
number
2. <CreditTransferTransactionInformation><Tax>
<ReferenceNumber> (e.g., case reference number)
96 | P a g e
Garnishment – DED Segment
Garnishments made by third parties, such as employers to government agencies for child support are supported
through the use of the DED segment in the ACH addenda. The ISO equivalent and mappings for DED01–DED09 are
provided below for the pain.001 message. Note that not all data elements fall within the Remittance Information
section of the ISO message.
Table 3: NACHA Endorsed Banking Convention – DED Mapping to ISO Equivalent*

Indicates the type of deduction being <PaymentInformation><PaymentTypeInformation>
DED01 Application Identifier
withheld from an employee’s pay <CategoryPurpose><Code>
The case identifier element is the IV-D case
number or court order number. The case
identifier always refers to the identification <RemittanceInformation><Structured>
DED02 Case Identifier
number of the case in the state receiving <ReferredDocumentInformation><Number>
the EFT/EDI transaction (e.g., the child
support SDU)
Provides the obligor’s (non-custodial
parent’s) pay date; the date the income <RemittanceInformation><Structured>
DED03 Pay Date
was withheld from the employee’s <ReferredDocumentInformation><RelatedDate>
paycheck
Indicates the non-custodial parent’s child
<RemittanceInformation><Structured>
DED 04 Payment Amount support withheld for this pay period, which is
<ReferredDocumentAmount><DuePayableAmount>
being paid to the SDU
Non Custodial Parent Provides the SDU with the non-custodial <PaymentInformation><UltimateDebtor><Identification>
DED 05
SSN parent’s Social Security number <PrivateIdentification><Other><Identification>
Medical Support Indicates whether the employer offers family <RemittanceInformation><Structured>
DED 06
Indicator medical insurance coverage <AdditionalRemittanceInformation>
indicates the first seven letters of the
Non Custodial Parent
DED 07 obligor’s last name followed by the first <PaymentInformation><UltimateDebtor><Name>
Name
three letters of his/her first name
The Federal Information Process Standard
<RemittanceInformation><Structured>
DED 08 FIPS Code (FIPS) code refers to the FIPS Code of the
<CreditorReferenceInformation><Reference>
SDU receiving the transaction
Employment The employment termination indicator is <RemittanceInformation><Structured>
DED 09
Termination Indicator used to notify the child support enforcement <AdditionalRemittanceInformation>
97 | P a g e
agency that an individual’s employment
has terminated
b. CTX Addenda
The Corporate Trade Exchange (CTX) format supports the transfer of funds within a trading partner relationship utilizing a
full ANSI ASC X12 message, or when payment-related UN/EDIFACT information is sent with the funds transfer. CTX can
accommodate the transmission of a maximum of 9,999 addenda records each carrying 80 characters of payment related
data (to pay multiple invoices) in the “7” record of the NACHA file. A common type of remittance application is the limited
ANSI X12 STP 820 and DED (Child Support Garnishment).
Note that NACHA does not offer mapping of ISO 20022 messages to the full ANSI X12 820 transaction set. Corporations and
financial institutions should work together to identify existing EDI data requirements and compliance with trading partner
needs.
98 | P a g e
1) Structured Data – STP 820 (EDI)
The STP 820 is a limited remittance advice grouped by the following:
 Remittance Information (RMR)

 Reference Information (REF)
 Date Information (DTM)
 Adjustment Information (ADX)
STP 820 specifies up to 10 required data elements, with two elements -- customer name and customer account
number (N1 segments) – that are part of the payment information as mandatory. When invoices are being paid, there
are eight additional fields such as invoice number, gross invoice amount, and amount paid to be included with the
electronic payment for each invoice being paid. The ISO equivalent found in the
<RemittanceInformation><Structured> section is provided in the table that follows.
Table 4: STP 820 Mapping to ISO Equivalent
STP 820
Data Element ISO 20022 Equivalent
Segment
Remittance Information or RMR
RMR01 Reference Identification Qualifier [IV, PO, R7] <ReferredDocumentInformation><Type><CodeOrProprietary><Code>
Reference Identification (e.g., Invoice
RMR02 <ReferredDocumentInformation><Number>
Number]
RMR03 Payment Action Code (not typically used) Set to *
RMR04 Monetary Amount [Amount Paid] <ReferredDocumentAmount><RemittedAmount>
RMR05 Monetary Amount [Invoice Amount] <ReferredDocumentAmount><DuePayableAmount>
RMR06 Monetary Amount [Adjustment Amount] <ReferredDocumentAmount><DiscountAppliedAmount>
Reference Information or REF
Reference Identification Qualifier [BM, PO,
REF01 <CreditorReferenceInformation><Type><CodeOrProprietary><Code>
R7, VV]
Reference Identification (e.g., PO Number,
REF02 <CreditorReferenceInformation><Reference>
Voucher Number)
REF03 Description <AdditionalRemittanceInformation>
99 | P a g e
Date / Time Information or DTM
DTM01 Date / Time Qualifier [003, 004, 092] Map qualifier based on RMR01
DTM02 Date <ReferredDocumentInformation><RelatedDate>
Adjustment Information or ADX
ADX01 Monetary Amount [Adjustment Amount] <ReferredDocumentAmount><AdjustmentAmountAndReason><Amount>
ADX02 Adjustment Reason Code <ReferredDocumentAmount><AdjustmentAmountAndReason><Reason>
Reference Identifier Qualifier (Code
ADX03
qualifying reason for change) <ReferredDocumentAmount><AdjustmentAmountAndReason>
Reference Identification (Additional <AdditionalInformation>
ADX04
descriptive information)
Originator and Receiver Name Identification or N1
N1 – Originator Name Identification or “Payer”
N101 Entity Identifier Code (PR = Payer) <Invoicee> implies entity identifier “PR”
N102 Payer Name {Mandatory field} <Invoicee><Name>
Payer Identification Code Qualifier (Code
designating the system/method of code <Invoicee><Identification><OrganisationIdentification><Other><SchemeName>
N103
structure used for Identification Code e.g., 1= <Code>
DUNS, 24 = Employer ID )
Identification Code (Payer Tax ID or
N104 Customer Account Number) {Mandatory <Invoicee><Identification><OrganisationIdentification><Other><Identification>
field}
N1 – Receiver Name Identification or “Payee”
N101 Entity Identifier Code (PE = Payee) <Invoicer> implies entity identifier “PE”
N102 Payee Name <Invoicer><Name>
Additionally, payment related data other than those noted above may also be transmitted within the structured
remittance information. These include such information as tax amount, address, etc.
100 | P a g e
2) Comparison of ISO 20022 XML Syntax with STP 820
Provided below is a comparison between STP 820 data elements and ISO 20022 equivalent XML information.
Table 5: Comparison of STP 820 to ISO Structure
Reference Information STP 820 (EDI) Structure ISO 20022 XML Structure
1 Customer Account Number N104 <Invcee>

N1*PR*ABC Corporation*91*C1234567\ <OrgId>...
<Id>C1234567</Id>
2 Customer Name N102 <Nm>ABC Corporation</Nm>
ABC Corporation
3 Invoice Number IV = Invoice number <RfrdDocInf>
RMR*IV*4562**9500.00*10000.00*500.00\ <Tp>
<CdOrPrtry>
<Cd>CINV</Cd>
</CdOrPrtry>
</Tp>
<Nb>4562</Nb>
<RltdDt>2012-09-08</RltdDt>
</RfrdDocInf>
4 Invoice Date DTM02
DTM*003*20120908\ <RltdDt>2012-09-08</RltdDt>
5 Invoice Gross Amount/ RMR05 <RfrdDocAmt>
Amount before Discounts RMR*IV*4562**9500.00*10000.00*500.00\ <DuePyblAmt Ccy="USD">10000.00</DuePyblAmt>
</RfrdDocAmt>
6 Amount Paid RMR04 <RfrdDocAmt>
RMR*IV*4562**9500.00*10000.00*500.00\ <RmtdAmt Ccy="USD">9500.00</RmtdAmt>
</RfrdDocAmt>
7 Discount Amount RMR06 <RfrdDocAmt>
RMR*IV*4562**9500.00*10000.00*500.00\ <DscntApld Amt Ccy="USD">500.00</DscntApldAmt>
</RfrdDocAmt>
8 Purchase Order REF*PO*5722319* APPROVED BY JOE SMITH\ <CdtrRefInf>
<TP>
<CdOrPrtry>
<Cd>PUOR></Cd>
</Tp>
<Ref>5722319</Ref>
</CdtrRefInf>
101 | P a g e
9 Adjustment Amount (ADX01) ADX*-8.98*01\ <AdjstmntAmtAndRsn>
<CdtDbtInd>DBIT</CdtDbtInd>
<Rsn>01</Rsn>
</AdjstmntAmtAndRsn>
10 Adjustment Reason Code (ADX02) ADX*-8.98*01\ <Rsn>01</Rsn>
CTX Remittance Example

The following provides an example of CTX addenda in a structured XML format.
Figure 11:
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Cd>CINV</CD>
</CdOrPrtry>
</Tp>
<Nb>A123456</Nb>
<RltdDt>2011-10-01</RltdDt>
</RfrdDocInf>
<RfrdDocAmt>
<DuePyblAmt Ccy=“USD”>100.00</DuePyblAmt>
<DscntApldAmt Ccy= “USD”>2.00</DscntApldAmt>
<TaxAmt Ccy=“USD”>0.00</TaxAmt>
<RmtdAmt Ccy=“USD”>98.00</RmtdAmt>
</RfrdDocAmt>
<CrtrRefInf>
<Ref>56789546</Ref>
</CrtrRefInf>
<AddtlRmtInf>DISCOUNT ALLOWED PER JANE DOE CALL NOV 1</AddtlRmtInf>
</Strd>
102 | P a g e
3) DED
Many states allow employers to remit child support payments electronically using the NACHA CTX format containing
ASC X12 820 Payment Order/Remittance Advice Transaction Set or the NACHA CCD format. Use of the CTX/820
enables an employer to send multiple child support payments with remittance information in one transaction set with a
maximum allowance of 9,999 Addenda Records to a State Disbursement Unit. For guidance and examples of ISO
20022 Mapping to DED Child Support Segment, please refer to the earlier CCD Addenda Section.
Note that while this Guide offers documentation for the future support of ISO 20022-based XML remittance addenda
for DED Segment, given that state agencies today do not accept XML data, NACHA does not support the transmission
of XML messages for this segment at this time. However, this information has been included in preparation for when
markets evolve.
c. IAT Addenda
The IAT addenda records are taken up by data elements defined by the Bank Secrecy Act’s “Travel Rule” information (i.e.,
Originator name, address, account number; Originator's depository institution name and payment amount; Receiver
name, address, account number; and the Receiver's financial institution) to comply with OFAC-sanctioned guidance. In its
existing state, there is limited space to transmit payment related data. Any data elements relating to payment instructions
screened against sanctions lists will need to apply to remittance information as well. Given the originator and receiver must
be able to open up the payment “envelope” to examine the addenda records for “bad” guys, today’s practice is to
provide a reference source for additional information for re-association in an unstructured format (see below example), or
in a structured related remittance information specifying a separate location the remittance advice has been sent. For
transmission to the clearing system, it is recommended that the XML tags are dropped and to include the remittance
information in the “7” record of the NACHA file.
Figure 12: Free Text IAT Addenda

<Ustrd>Invoice 1234</Ustrd>
103 | P a g e
5. Same Day ACH
Originators can indicate the intent for a U.S. ACH payment to be sent “today” by including “today’s date” in the “Requested Entry
Date” field in the payment instruction pain.001 for same day processing. The Effective Entry Date in an ACH transaction is the required
indicator for Same Day ACH transactions.
The use of “Company Descriptive Date” field is an optional indicator for a Same Day ACH transaction, and its use is at the discretion of
the ODFI. Valid content may be either “SD1300” or “SD1700,” which denotes same day processing and the military designation
“HHMM” for the hour and minutes that correspond to the desired settlement timing of either 1:00 PM ET or 5:00 PM ET. As this field is
optional the ACH Operator will not validate this field.
Description chosen by the originator to No direct mapping. May be inserted into

8 Company Descriptive Date 6 64-69 O
identify the date for the receiver <AdditionalRemittanceInformation> field
For additional information on Same Day ACH requirements visit: https://resourcecenter.nacha.org/.
104 | P a g e
6. Exceptions – Returns and Rejects
In some cases, credit transactions from originating parties may be returned or rejected.
Unsuccessful execution before settlement results in a reject transaction. If it is after
settlement, the result is a return transaction. To better understand the flow of these
messages, please refer to the scenarios presented at the beginning of this document
(Section 2).
Rejects are transactions that may be diverted from normal execution by the ODFI or
Debtor Agent for reasons related to technical issues as invalid format, missing
information, etc. The reason information for a reject is included in the Customer Payment
Status Report or pain.002 message.
Returns are funds sent back by the Payee or Receiver to the Payer or Originator following
settlement of the original payment instruction. The reason for the return will usually be
reported to the Originator, along with the reference number of the original payment
instruction in a Cash Management or camt message to facilitate reconciliation. The
possible reasons for rejects and returns are translated into a standardized (ISO) reason
code available in the ISO External Code List:
http://www.iso20022.org/external_code_list.page.
NACHA guidance on returns and rejects are available separately on the ISO 20022
Resource Center: https://www.nacha.org/ISOresources.
105 | P a g e
7. 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 pain.001.001.03 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
These identifier fields include the following:
Mandatory Fields
 End-to-End Identification
 Message Identification
 Payment Information Identification
Optional Fields
 Instruction Identification
 Creditor and Debtor Identification
 Ultimate Debtor/Creditor Identification
 Remittance Information
 Proprietary Codes
1) Basic Latin
The Basic Latin Unicode block is the first block of the Unicode standard. The
block also incorporates ASCII (American Standard for Information
Interchange) accepted in NACHA file formats. 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
106 | P a g e
Character Description
, comma
‘ apostrophe
+ plus
space
= equal to
! exclamation mark
“ quotation mark
% percent
& ampersand
* asterisk
< less than
> greater than
; semi-colon
@ at
# 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) >
107 | P a g e
Special Characters XML Representation
& (ampersand) &
As an example, AB & C Transport would populate their name in a pain.001

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.
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 pain.001 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 pain.001.001.03.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
108 | P a g e
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
3) European Payments Council (EPC) Guidelines for SEPA Transactions

Message Implementation Guidelines for ISO 20022 XML SEPA Credit Transfers
can be downloaded from the EPC website:
http://www.europeanpaymentscouncil.eu/index.cfm/sepa-credit-
transfer/sepa-credit-transfer-sct/
109 | P a g e
8. Revision History
Version Date Summary of Changes

1.0 April 2015 Creation Date
2.0 March 2016 Document updated with minor amendments
including Outbound IAT only
3.0 November 2016 Small modifications based on additional industry
feedback on treatment of certain NACHA fields
i.e., File ID Modifier and Batch Number.
Document enhanced to include:

 Support of PPD
 Same Day ACH
 Remittance details with CTX
110 | P a g e

Pain, Ach, CTX and Nacha

Uploaded by

Copyright:

Available Formats

Pain, Ach, CTX and Nacha

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pain, Ach, CTX and Nacha

Uploaded by

Copyright:

Available Formats

NACHA ISO 20022 Credit

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

a. Parties of the Transaction

ISO 20022 Synonym Description

Figure 1: ISO 20022 Payment Process Flows

Interbank Clearing and Settlement

Debtor Agent / ODFI* Creditor Agent / RDFI*

Customer Direct Debit

Debtor / Originator* Creditor / Receiver*

c. pain.001 XML Payment Message File Structure

Figure 2: pain.001 XML File Structure

Group Header (1..1)

Payment Information (1..n)

3) Credit Transfer Transaction Information

The optional Remittance Information can be repetitive when used to

It should be noted that this Guide offers documentation for remittance

It is important to be aware of possible overpopulation in an XML message and to

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

Translate Interbank Clearing and Settlement

Debtor / Originator Creditor / Receiver

Example 1: File Header Record “1”

Figure 4: NACHA File Format

XML File Format

Example 2: Company / Batch Header Record “5”

Company Name: ABHC CLM PMT CR

XML File Format

Payment Information Block XML Message

Example 3: Entry Detail Record “6”

Receiving DFI Identification (RDFI bank transit routing number): 11100002

XML File Format

Credit Transfer Transaction Information 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..1] = optional, only one occurrence

[0..n] = optional and repetitive

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

 Type: identifies data type and size

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

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

Payment Information (Batch) / Transaction Level – There are a number of

Maps to NACHA Format

<?xml version=”1.0” encoding=”UTF-8”?> The XML header must follow the

Group Header Block

ISO Maps to NACHA Format

Note: This ID cannot be

ISO Maps to NACHA Format

ISO Maps to NACHA Format

Payment Information Block – This can occur multiple times

ISO Maps to NACHA Format

ISO Maps to NACHA Format

Specifies the local

ISO Maps to NACHA Format

1. For CCD, PPD and CTX,

ISO Maps to NACHA Format