2 0 1 3

NACHA
Operating Rules
& Guidelines
C O R P O R AT E E D I T I O N

© 2013 NACHA — The Electronic Payments Association®

All rights reserved.

No part of this publication may be reproduced, retransmitted, transferred or displayed, in any form or by any means,
electronic or mechanical, including by photocopy, digital transmission, recording or any information storage and
retrieval system, without the prior written permission of NACHA. Requests for permission to make copies or otherwise
reproduce, retransmit or otherwise exploit content of any part of this publication should be mailed or emailed to:

Permissions
NACHA – The Electronic Payments Association
13450 Sunrise Valley Drive, Suite 100
Herndon, VA 20171
[email protected]

This publication is designed to provide accurate and authoritative information in regard to the subject matter covered.
It is sold with the understanding that the author/publisher is not engaged in rendering legal advice or providing any
other professional service, and NACHA does not guarantee or make any representations or warranties of any kind,
either express or implied, including warranties of merchantability and fitness for a particular purpose. If legal advice
or other professional assistance is required, the services of a competent professional person should be sought.
 REGIONAL PAYMENTS ASSOCIATIONS
ALABAMA ACH ASSOCIATION NEACH - NEW ENGLAND ACH ASSOCIATION THE CLEARING HOUSE PAYMENTS ASSOCIATION
2 Riverchase Office Plaza, Suite 111 35 Corporate Drive, Suite 190 450 West 33rd Street
Birmingham, AL 35244 Burlington, MA 01803 New York, NY 10001
Phone: (205) 733-0006 Phone: (781) 321-1011 Phone: (800) 875-2242
Email: [email protected] Email: [email protected] Email: [email protected]
EASTPAY SHAZAM, INC. THE PAYMENTS AUTHORITY, INC.
7400 Beaufont Springs Dr., Suite 405 6700 Pioneer Parkway 580 Kirts Blvd., Suite 301
Richmond, VA 23225 Johnston, IA 50131 Troy, MI 48084
Phone: (800) 681-4224 Phone: (800) 537-5427 Phone: (248) 688-9720
Email: [email protected] Email: [email protected] Email: [email protected]
With offices also in:
Birmingham, AL SOUTH CAROLINA ACH ASSOCIATION UPPER MIDWEST ACH ASSOCIATION
Charlotte, NC 7440 Broad River Road 7100 Northland Circle, Suite 407
Longwood, FL Irmo, SC 29063 Brooklyn Park, MN 55428
Phone: (803) 732-1579 Phone: (763) 549-7000
EPCOR Email: [email protected] Email: [email protected]
3100 Broadway, Suite 609
Kansas City, MO 64111 SOUTHERN FINANCIAL EXCHANGE VIEWPOINTE CS & ASSOCIATION SERVICES
Phone: (800) 500-0100 1340 Poydras Street, Suite 2010 5025 North Central Avenue, Suite 427
Email: [email protected] New Orleans, LA 70112 Phoenix, AZ 85012
Phone: (504) 525-6779 Phone: (800) 279-9059
GACHA Email: [email protected] Email: [email protected]
3250 Riverwood Parkway, Suite 150
Atlanta, GA 30339 SWACHA - THE ELECTRONIC PAYMENTS RESOURCE WACHA - THE PREMIER PAYMENTS RESOURCE
Phone: (678) 384-9791 1999 Bryan Street, Suite 3600 W177 N9886 Rivercrest Drive, Suite 112
Email: [email protected] Dallas, TX 75201 Germantown, WI 53022
Phone: (800) 475-0585 Phone: (262) 345-1245
MACHA - THE MID-ATLANTIC PAYMENTS ASSOCIATION Email: [email protected] Email: [email protected]
1344 Ashton Road, Suite 202
Hanover, MD 21076 TENNESSEE ACH ASSOCIATION WESPAY
Phone: (410) 859-0090 1000 NorthChase Dr., Suite 201 300 Montgomery Street, Suite 400
Email: [email protected] Goodlettsville, TN 37072 San Francisco, CA 94104
Phone: (615) 859-4188 Phone: (800) 977-0018
Email: [email protected] Email: [email protected]

DIRECT FINANCIAL INSTITUTION MEMBERS

AMERICAN EXPRESS CENTURION BANK HUNTINGTON NATIONAL BANK STATE BANK & TRUST COMPANY
4815 South 2700 West, MC 02-02-16 41 S High St 3399 Peachtree Rd NE, Suite 1800
Salt Lake City, UT 84184 HC0445 Atlanta, GA 30326
Phone: (801) 945-6569 Columbus, OH 43215 Phone: (404) 266-4612
Email: [email protected] Phone: (614) 480-4957 Email: [email protected]
Email: [email protected]
BANK OF AMERICA MERRILL LYNCH SILICON VALLEY BANK
1455 Market St J.P. MORGAN 4750 West 2100 South, Suite 300
Mail Code: CA5-701-04-71 10430 Highland Manor Drive Salt Lake City, UT 84120
San Francisco CA 94103-1399 Tampa, FL 33610 Phone: (801) 977-3636
Phone: Phone: (800) 446-0135 Phone: (813) 432-3779 Email: [email protected]
Email: [email protected] Email: [email protected]
SUNTRUST BANK
BB&T KEYBANK 303 Peachtree Center Ave., Suite 375
1717 King Street, MC 468 01 01 00 127 Public Square Atlanta, GA 30303
Alexandria, VA 22314 MC OH-01-27-0723 Phone: (404) 588-8274
Phone: (703) 549-1883 Cleveland, OH 44114 Email: [email protected]
Email: [email protected] Phone: (216) 689-4611
Email: [email protected] TCF NATIONAL BANK
BMO HARRIS BANK 801 Marquette Ave
111 W Monroe St M&T Bank MC-001-14-B
9E Fl 465 Main St. Minneapolis, MN 55402
Chicago, IL 60603 Buffalo, NY 14203 Phone: (612) 661-6692
Phone: (312) 461-7162 Phone: (716) 848-4798 Email: [email protected]
Email: [email protected] Email: [email protected]
TD BANK, N.A.
BNY MELLON MERRICK BANK CORPORATION 6000 Atrium Way
500 Ross Street 10705 S Jordan Gateway, Suite 200 MC NJ5-002-121
Mellon Client Service Ctr Rm 154-0960 S. Jordan, UT 84095 Mt. Laurel, NJ 08054
Pittsburgh, PA 15262 Phone: (801) 545-6619 Phone: (856) 380-2069
Phone: (412) 236-3338 Email: [email protected] Email: [email protected]
Email: [email protected]
METABANK THE BANCORP BANK
CAPITAL ONE 5501 S Broadband Lane 409 Silverside Road, Suite 105
15000 Capital One Drive Sioux Falls, SD 57108 Wilmington, DE 19809
12070-3333 Phone: (605) 782-0977 Phone: (610) 304-8573
Richmond, VA 23238 Email: [email protected] Email: [email protected]
Phone: (866) 561-2580
Email: [email protected] NAVY FEDERAL CREDIT UNION UMB BANK, N.A.
820 Follin Lane SE 1010 Grand Blvd., MS 1020214
CITIBANK N.A. Vienna, VA 22180 Kansas City, MO 64106
One Penn’s Way Phone: (703) 206-3919 Phone: (816) 860-5667
New Castle, DE 19720 Email: [email protected] Email: [email protected]
Phone: (877) 340-4357
Email: [email protected] PNC BANK U.S. BANK
500 First Ave 800 Nicollet Mall
DISCOVER FINANCIAL SERVICES, INC. 3rd Fl PNC Firstside Center MS P7-PFSC-03-C MC BC-MN-H2OP
2500 Lake Cook Road Pittsburgh, PA 15219 Minneapolis, MN 55402
Riverwoods, IL 60015 Phone: (412) 762-4008 Phone: (612) 303-7334
Phone: (224) 405-1661 Email: [email protected] Email: [email protected]
Email: [email protected]
RBS CITIZENS BANK WELLS FARGO
FIFTH THIRD BANK 28 State Street 625 Marquette Ave
38 Fountain Square Plaza Boston, MA 02109 Suite 1000 10th Fl MAC N9311-100
MD 1090LA Phone: (617) 725-5861 Minneapolis, MN 55402
Cincinnati, OH 45263 Email: [email protected] Phone: (612) 667-5974
Phone: (513) 534-3200 EMail: [email protected]
Email: [email protected] REGIONS FINANCIAL CORP
201 Milan Pkwy ZIONS BANCORPORATION
FIRST PREMIER BANK MC ALBH70206A 2200 South 3270 West
400 S Sycamore Ave., Suite 101 Birmingham, AL 35211 Salt Lake City, UT 84119
Sioux Falls, SD 57110 Phone: (205) 420-5836 Phone: (888) 315-2271
Phone: (605) 357-3093 Email: [email protected] Email: [email protected]
Email: [email protected]
 INTRODUCTION

Introduction

The NACHA Operating Rules & Guidelines – Corporate Edition is an annual publication produced by
NACHA — The Electronic Payments Association. NACHA manages the development, administration, and
governance of the ACH Network, the backbone for the electronic movement of money and data. The ACH
Network provides a safe, secure, and reliable network for direct account-to-account consumer, business,
and government payments. Annually, it facilitates billions of Direct Deposit via ACH and Direct Payment
via ACH transactions. Used by all types of financial institutions, the ACH Network is governed by a fair
and equitable set of rules that guide risk management and create payment certainty for all participants.
As a not-for-profit association, NACHA represents more than 10,000 financial institutions via 17 regional
payments associations and direct membership. Through its industry councils and forums, NACHA brings
together payments system stakeholders to foster dialogue and innovation to strengthen the ACH Network.

The NACHA Operating Rules (Rules) provide users with the legal framework for the ACH Network,
while the NACHA Operating Guidelines (Guidelines) provide guidance on implementing the Rules.
This rulebook serves as the definitive source of information governing the exchange and settlement of
electronic fund transfers through the ACH Network. In the case of any inconsistency or conflict between
the Rules and the Guidelines, the NACHA Operating Rules govern. The Rules are organized around the
types of participants in the ACH Network and acknowledge the major roles played by originating and
receiving financial institutions, therefore dedicating large sections to each of these roles. The Rules
explicitly recognize that originating financial institutions are the entry points into the ACH Network for
corporate users and Third Parties, and that these financial institutions are responsible for those parties’
compliance with the Rules.

HOW TO USE THIS BOOK

This publication is divided into two sections, the NACHA Operating Rules and the NACHA Operating
Guidelines – Corporate Edition.

The NACHA Operating Rules provides the legal foundation for the ACH Network. The introductory pages
of this section contain the following material.

• NACHA Board of Directors’ Policy Statements: This section provides guidance from the Board of
Directors on topics of importance to the ACH Network.

• Formal Rules Interpretations: This section contains formal interpretations of the NACHA Operating
Rules, as approved and issued by the NACHA Board of Directors. Interpretations contained in this
section are as binding as the NACHA Operating Rules themselves and have been issued to clarify the
provisions of the NACHA Operating Rules or to provide guidance about whether a particular use or
application is consistent with the Rules. Such interpretations may also have been issued for other
purposes, as deemed appropriate by the Board.

• Network Administration Fees: This section details the amounts of both the annual and per-entry fees,
as determined from time to time by the NACHA Board of Directors..

• Revisions to the NACHA Operating Rules & Guidelines: This section summarizes amendments to
the NACHA Operating Rules that have been approved by the NACHA voting membership during
the last year. Read this section first to get an overview of recent developments and their impact on
operations.
INTRODUCTION

• Supplement #2-2012 provides information on the newest ACH rules changes, which will take effect
in 2013. These changes were approved just prior to publication and are not included in the pages of
the NACHA Operating Rules and NACHA Operating Guidelines – Corporate Edition sections.

The body of the NACHA Operating Rules contains language relating to both current rules and rule
changes that will take effect later in the year. This edition of the Rules contains current rule language,
followed immediately by the new rule text, which is in italics and highlighted. Rule changes within the
text are indicated by a marker in the left margin, with approval and effective dates for those changes
noted at the bottom of the page.

Example:

SUBSECTION 2.17.2.2  ODFI Reduction of Return Rate

The ODFI must reduce the Originator’s or Third-Party Sender’s return rate for unauthorized
Entries to a rate below one percent within sixty days after receipt of the National Association’s
written request for information and maintain that return rate below one percent for an
additional one hundred eighty days.

u The ODFI must reduce the Originator’s or Third-Party Sender’s return rate for unauthorized
Entries to a rate below one percent within thirty days after receipt of the National Association’s
written request for information and maintain that return rate below one percent for an
additional one hundred eighty days.

Pages in the NACHA Operating Rules section are numbered sequentially beginning with the prefix “OR.”

The NACHA Operating Guidelines – Corporate Edition includes excerpts from the NACHA Operating
Guidelines that are important to corporations. Refer to the Guidelines for originator roles and
responsibilities within the ACH Network and an overview of Standard Entry Class Codes. In addition,
the NACHA Operating Guidelines – Corporate Edition offers details on the legal framework of the Rules,
Third-Party Service Providers, OFAC Compliance, and a brief history of the ACH Network.

Pages in the NACHA Operating Guidelines – Corporate Edition are numbered sequentially beginning with
the prefix “OG.”
 TA B L E O F C O N T E N T S

Table of Contents

NACHA Operating Rules

NACHA Board of Directors Policy Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ORi

Formal Interpretations of the NACHA Operating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ORxi

Network Administration Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ORxx

Revisions to the NACHA Operating Rules & Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ORxxv

Supplement #2-2012 to the NACHA Operating Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ORxxxix

ARTICLE ONE  General Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR1

SECTION 1.1 Application of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR1

SECTION 1.2  Participating DFIs Must Comply With Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR1
SECTION 1.3  Amending, Suspending and Interpreting the Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR2
SECTION 1.4  Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR2
SECTION 1.5  Excused Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR3
SECTION 1.6  Secure Transmission of ACH Information Via Unsecured Electronic Networks . . . . . . . . . . . . . . . . . . . . . OR3
SECTION 1.7  Choice of Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR3
SECTION 1.8  Beneficiaries of the Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR3
SECTION 1.9  Protection for the National Association from Frivolous Lawsuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR3
SECTION 1.10  Network Administration Fees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR4

ARTICLE TWO Rights and Responsibilities of ODFIs, Their Originators and

Third-Party Senders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR4
SECTION 2.1  General Rule – ODFI is Responsible for Entries and Rules Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . OR4
SECTION 2.2  Prerequisites to Origination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR4
SECTION 2.3  Authorization and Notice of Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR5
SECTION 2.4  General Warranties and Liabilities of Originating Depository
Financial Institutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR7

2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S i
TA B L E O F C O N T E N T S

SECTION 2.5  Provisions for Specific Types of Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR9

SECTION 2.6 Prenotifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR24
SECTION 2.7  Recall by ODFI or Originator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR24
SECTION 2.8  Reversing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR24
SECTION 2.9  Reversing Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR25
SECTION 2.10  Reclamation Entries and Written Demands for Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR25
SECTION 2.11  Notifications of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR27
SECTION 2.12  Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR27
SECTION 2.13  Refusal of Acknowledgment (ACK and ATX ) Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR28
SECTION 2.14  Return Fee Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR29
SECTION 2.15  Obligations of Third-Party Senders, and of ODFIs and Originators That Use Third-Party Senders . . . . OR30
SECTION 2.16  Authorization by ODFI for Release of Designated Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR30
SECTION 2.17  ODFI Reporting Requirements to National Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR31

ARTICLE THREE  Rights and Responsibilities of RDFIs and Their Receivers . . . . . . . . . . . . . OR33

SECTION 3.1  General Rights and Responsibilities of RDFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR33

SECTION 3.2  General Warranties and Liabilities of RDFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR35
SECTION 3.3  Timing Requirements for RDFI to Make Credit and Debit Entries Available . . . . . . . . . . . . . . . . . . . . . . . OR35
SECTION 3.4  Provisions for Receipt of Specific Types of Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR36
SECTION 3.5  Specific Provisions for Prenotifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR38
SECTION 3.6  Specific Provisions for Reclamation Entries and Written Demands for Payment . . . . . . . . . . . . . . . . . . . OR38
SECTION 3.7  RDFI Obligation to Stop Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR38
SECTION 3.8  RDFI’s Right to Transmit Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR39
SECTION 3.9  Notification of Change by RDFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR41
SECTION 3.10  Specific Provisions for Acknowledgment (ACK and ATX) Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR42
SECTION 3.11  RDFI Obligation to Recredit Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR42
SECTION 3.12  Written Statement of Unauthorized Debit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR43
SECTION 3.13  RDFI Right to Transmit Extended Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR45

ARTICLE FOUR  Rights and Responsibilities of ACH Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . OR46

SECTION 4.1  General Responsibilities of ACH Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR46
SECTION 4.2  Processing Obligations of ACH Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR46
SECTION 4.3  Reversing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR47
SECTION 4.4  ACH Operator Not Agent of Participating DFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR47
SECTION 4.5  ACH Operator Must Retain Records of Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR47
SECTION 4.6  Requirement to Provide Designated Data to National Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR48
SECTION 4.7  Automated Accounting Advices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR48
SECTION 4.8  Optional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR48

ii 2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S
 TA B L E O F C O N T E N T S

ARTICLE FIVE  Rights and Responsibilities of Gateways for IAT Entries . . . . . . . . . . . . . . . . . . OR48
SECTION 5.1  Responsibilities of Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR48
SECTION 5.2  Warranties of Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR49
SECTION 5.3  Gateway Assumes Obligations of Other Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR49

ARTICLE SIX  Rights and Responsibilities of the National Association . . . . . . . . . . . . . . . . . . . . OR50

SECTION 6.1  Use and Disclosure of Designated Data by the National Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR50
SECTION 6.2  Indemnity by National Association of ACH Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51
SECTION 6.3  Limitation of Liability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51

ARTICLE SEVEN  Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51

SECTION 7.1  Maintenance of Reserve Bank Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51
SECTION 7.2  ACH Operators Establish Settlement Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51
SECTION 7.3  Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51
SECTION 7.4  Effect of Settlement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR51
SECTION 7.5  Accountability for Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR52
SECTION 7.6  Effect of RDFI Closing on Settlement Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR52
SECTION 7.7  Effect of ODFI Closing on Settlement Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR52
SECTION 7.8  Non-Settled Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR52

ARTICLE EIGHT  Definitions of Terms Used in These Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR52

APPENDIX ONE  ACH File Exchange Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR62

PART 1.1  Electronic Transmission Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR62
PART 1.2  Data Specifications for ACH Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR62
PART 1.3  Sequence of Records in ACH Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR62
PART 1.4  File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR63
PART 1.5  Trace Number Sequence in ACH Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR65

APPENDIX TWO  Specifications for Data Acceptance by ACH Operators . . . . . . . . . . . . . . . . . . OR68

PART 2.1  File Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR68
PART 2.2  Originator Status Code Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR68
PART 2.3  Automatic File Rejection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR68
PART 2.4  Automatic Batch or File Rejection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR69
PART 2.5  Automatic Entry Detail Rejection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR70

APPENDIX THREE  ACH Record Format Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR73

PART 3.1  Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR73
PART 3.2  Glossary of ACH Record Format Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR102

2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S iii
TA B L E O F C O N T E N T S

APPENDIX FOUR  Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR126

PART 4.1  Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR126
PART 4.2  Table of Return Reason Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR127
PART 4.3   Record Formats for Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR146
PART 4.4  Dishonored Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR157
PART 4.5  Contested Dishonored ACH Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR162

APPENDIX FIVE  Notification of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR167

PART 5.1  Notification of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR167
PART 5.2  Refused Notification of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR167
PART 5.3  Table of Change Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR168
PART 5.4  Record Formats for Notifications of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR173

APPENDIX SIX  Acknowledgment Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR185

PART 6.1  Acknowledgment Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR185
PART 6.2  Refused Acknowledgment Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR185
PART 6.3   Table of Codes for Refused Acknowledgment Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR185
PART 6.4  Record Formats for Acknowledgment and Refused Acknowledgment Entries . . . . . . . . . . . . . . . . . . . . . . . . OR185

APPENDIX SEVEN  Compensation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192

PART 7.1  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192
PART 7.2  Nature of the Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192
PART 7.3  Manner of Payment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192
PART 7.4  Beneficiaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192
PART 7.5  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR192
PART 7.6  Back Valuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR193
PART 7.7  Forward Valuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR193
PART 7.8  Return or Reversal of Erroneous Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR193
PART 7.9  Change of Beneficiary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR194

APPENDIX EIGHT  Rule Compliance Audit Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR195

PART 8.1  General Audit Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR195
PART 8.2  Audit Requirements for All Participating DFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR195
PART 8.3  Audit Requirements for RDFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR196
PART 8.4  Audit Requirements for ODFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR198

APPENDIX NINE  Arbitration Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR200

PART 9.1  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR200
PART 9.2  Filing a Complaint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR200
PART 9.3  Classification of Disputes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR200

iv 2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S
 TA B L E O F C O N T E N T S

PART 9.4  Selection of Arbitrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR201

PART 9.5  Presentation of the Case and the Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR201
PART 9.6  Payment and Appeal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR202

APPENDIX TEN  Rules Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR203

PART 10.1  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR203
PART 10.2  ODFI Reporting Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR203
PART 10.3  ODFI Registration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR204
PART 10.4  National System of Fines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR204

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OR211

NACHA Operating Guidelines –

Corporate Edition

SECTION I  General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG1

CHAPTER 1  Overview of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG1

CHAPTER 2  Legal Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG9
CHAPTER 3  OFAC Requirements and Obligations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG12
CHAPTER 4  General Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG21

SECTION II  Originating Depository Financial Institutions . . . . . . . . . . . . . . . . . . . . . . . OG25

PART TWO – RIGHTS AND RESPONSIBILITIES OF ORIGINATORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG25

CHAPTER 15  Relationship with ODFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG26
CHAPTER 16  Relationship with Receiver and Authorization Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG27
CHAPTER 17  Initiation of Forward Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG35
CHAPTER 18  Originators and Return and Dishonored Return Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG40
CHAPTER 19  Originators and Prenotifications and Notifications of Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG44
CHAPTER 20  Originators and Reversals and Reclamations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG46

PART THREE – RIGHTS AND RESPONSIBILITIES OF THIRD-PARTY SENDERS . . . . . . . . . . . . . . . . . . . . OG48

CHAPTER 21  Relationship with Originators and ODFIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG48

2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S v
TA B L E O F C O N T E N T S

SECTION V  Standard Entry Class Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG49

CHAPTER 36  Acknowledgment Entries (ACK & ATX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG49
CHAPTER 37  Accounts Receivable Entries (ARC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG50
CHAPTER 38  Back Office Conversion Entries (BOC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG57
CHAPTER 39  Corporate Credit or Debit and Corporate Trade Exchange Entries (CCD & CTX) . . . . . . . . . . . . . . . . . . OG63
CHAPTER 40  Customer-Initiated Entries (CIE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG72
CHAPTER 43  International ACH Payments (IAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG81
CHAPTER 44  Point of Purchase Entries (POP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG109
CHAPTER 45  Prearranged Payment and Deposit Entries (PPD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG114
CHAPTER 46  Re-Presented Check Entries (RCK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG118
CHAPTER 47  Telephone-Initiated Entries (TEL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG122
CHAPTER 48  Internet Initiated/Mobile Entries (WEB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG127

SECTION VI  Special Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG135

CHAPTER 50  Third-Party Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG135
CHAPTER 53  Interpretative Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG147
CHAPTER 54  Return Fee Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG149
CHAPTER 55  Healthcare EFT Regulations and the ACH Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG153

SECTION VII  Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG161

APPENDIX A  History of the ACH System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG161
APPENDIX B  Standard Entry Class Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG165
APPENDIX C Issues To Be Addressed in the Agreement Between the ODFI and the
Originator or Third-Party Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG168
APPENDIX D  Document Retention Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG170
APPENDIX E  Source Document Eligibility Charts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG171
APPENDIX F  Sample Authorization for Direct Deposit and Split Deposit via ACH (ACH Credit) . . . . . . . . . . . . . . . . . . OG173
APPENDIX G  Sample Authorization for Direct Payment via ACH (ACH Debit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG174
APPENDIX H  Guidelines for Consumer Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG175
APPENDIX J  Basic ASC X12 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OG179

vi 2 0 1 3 O P E R AT I N G R U L E S & G U I D E L I N E S
NACHA Operating Rules
 N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

NACHA Board of Directors Policy Statements

NACHA Board of Directors Policy Statement

on Data Security

The following Data Security Policy Statement was originally adopted by the Board of Directors on
November 13, 1986, and revised on June 9, 2010.

NACHA strongly supports the efforts of ACH Network participants to implement state-of-the-art data
security techniques. On an ongoing basis, ACH Network participants should stay abreast of new data
security techniques and their applicability to the ACH Network to ensure a high level of quality and
reliability to all users of the ACH Network.

2 0 1 3 O P E R AT I N G R U L E S ORi
N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

NACHA Board of Directors Policy Statement

on Fraud Prevention and Risk Management Initiatives

The following Policy Statement on Fraud Prevention and Risk Management Initiatives was adopted by the
Board of Directors on August 22, 2002.

Fraud and various forms of financial abuse have found their way into every facet of the U.S. payment
systems. The NACHA Board believes that the Automated Clearing House Network must maintain the
highest standards of fraud prevention to retain the integrity of the payment mechanism and the trust and
confidence of its users. Therefore, the NACHA Board resolves and strongly urges that all participants
implement adequate control systems to detect and prevent fraud and abusive financial transactions.

ORii 2 0 1 3 O P E R AT I N G R U L E S
 N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

NACHA Board of Directors Interim Policy Statement on

ACH Data Breach Notification Requirements

The following Interim Policy Statement on ACH Data Breach Notification Requirements was adopted by
the Board of Directors on September 28, 2007.

POLICY SUMMARY
This interim policy concerns the timely and accurate notification of NACHA and affected RDFIs when
ODFIs or their Originators or third-party service providers know or reasonably suspect (i) that Consumer-
Level ACH Data (defined below) has been lost, stolen or otherwise subject to unauthorized access and
(ii) that misuse of such information has occurred or is reasonably possible. This interim policy is not
intended to address data comparable to that contained in ACH files that is obtained from other sources,
such as check collection.

This interim policy is effective September 28, 2007. Compliance with this interim policy will not be
enforced as a rule until NACHA has adopted a formal rule regarding data breaches; however, the Board
expects that institutions will take advantage of the notification procedures described here in order to
better manage the risk arising out of data breaches that involve Consumer-Level ACH Data. This interim
policy does not supersede any other data breach notification requirements to which ACH Network
participants may be subject under applicable law or regulation.

DATA BREACH EVENT

For purposes of this interim policy, a “data breach” is defined as the loss, theft or unauthorized access
of Consumer-Level ACH Data by or from any ODFI or Originator or any of their respective third-party
service providers using the ACH Network, or any affiliate of the foregoing under circumstances indicating
that the misuse of such information has occurred or is reasonably possible.

CONSUMER-LEVEL ACH DATA

With respect to this interim policy, Consumer-Level ACH Data means the following information with
respect to consumer customers of an RDFI gathered by an ODFI or Originator or any of their respective
third-party service providers for the purpose of initiating ACH transactions:

(1) a bank account number together with a bank routing number; or

(2) the customer’s name together with the customer’s social security number

This policy does not apply to information that is received for any other purpose, such as bank routing
numbers and account numbers that are used in check processing. Consumer-Level ACH Data that are
created from checks in connection with ACH check conversion or truncation programs are covered by
this interim policy.

PREVENTION
Each ODFI is responsible for ensuring that it, its Originators, and their respective third party service
providers adopt and implement commercially reasonable policies, procedures and systems to receive,
store, transmit and destroy Consumer-Level ACH Data in a secure manner and to protect against
data breaches.

2 0 1 3 O P E R AT I N G R U L E S ORiii
N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

DETECTION, INVESTIGATION AND ESCALATION

Each ODFI is responsible for ensuring that it, its Originators, and their respective Third Party Service
Providers implement commercially reasonable policies, procedures and systems to detect the occurrence
of a data breach within their respective organizations.

Those policies and procedures should include escalation of any breach to appropriate personnel within
the organization in a timely fashion, and in the case of Originators and third party service providers,
prompt notice to the designated security contact at the ODFI.

If a data breach is known or suspected, the ODFI and its affected Originator and/or third party service
provider should immediately commence and diligently pursue an investigation of the circumstances to
determine (i) if a data breach has actually occurred, (ii) the scope of the data breach, including the type
and amount of data affected, (iii) the risk that the affected data will be misused, and (iv) what steps are
necessary to prevent further unauthorized access to Consumer-Level ACH Data.

NOTIFICATION OF NACHA AND RDFIS

If an ODFI knows or reasonably suspects (i) that Consumer-Level ACH Data in its control or the control
of one of its Originators or third party services providers has been lost, stolen or otherwise subject to
unauthorized access and (ii) that misuse of such information has occurred or is reasonably possible, the
ODFI should notify the NACHA security contact.1 The ODFI’s notification to NACHA must provide the
following findings concerning the data breach incident:

1. Approximate cause(s) of the breach incident

2. Approximate date of the breach incident

3. Approximate size of the affected population (victims)

4. The type of data exposed

5. The routing and transit numbers (RTNs) of the affected RDFI accounts

6. The ODFI’s designated security contact for inquiries from RDFIs

7. Organizations that are involved in the breach (this information may be limited to NACHA at the
request of the ODFI).

Other relevant findings that may be included in the notification are as follows:2

8. Any mitigating factors

9. Any other information the ODFI believes would be relevant to an RDFI’s evaluation of the data
breach and response to it.

NACHA may provide a standardized form that may be used for purposes of notification in accordance
with this policy. If the notice to NACHA is returned undelivered, the ODFI must take reasonable steps to
correct the address and resend promptly.

1
The ODFI, Originator and third-party processor must separately determine whether they have any consumer notification requirements under
applicable law.
2
While these additional findings will be helpful for disclosure purposes, their determination should not delay the required notification.

ORiv 2 0 1 3 O P E R AT I N G R U L E S
 N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

The ODFI also should take reasonable steps to notify RDFIs whose accounts may be affected, which
may include, at the option of the ODFI, directly contacting each RDFI, or using a process designated by
NACHA to help enable such contacts.

TIMEFRAME TO NOTIFY
The ODFI must take all appropriate steps to provide initial notice to NACHA and each affected RDFI as
soon as reasonably possible. ODFIs should not wait to complete their investigation before providing
initial notice if sufficient information has been elicited (i) to conclude that a data breach likely occurred
and that misuse of Consumer-Level ACH Data is reasonably possible and (ii) to allow RDFIs to take
meaningful action in response to such notice.

Notice may be delayed or limited if disclosure of the information to ACH Network participants would
impede an on-going criminal investigation.

2 0 1 3 O P E R AT I N G R U L E S ORv
N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

NACHA Board Of Directors Policy Statement

on Use of a Terminated Originator Database

The following Policy Statement on Use of a Terminated Originator Database was adopted by the Board of
Directors on October 21, 2010.

POLICY SUMMARY
This policy addresses the importance of Originating Depository Financial Institution (ODFI) use of
a Terminated Originator Database as a component of an ODFI’s due diligence and risk management
processes, which are essential to the maintenance of a high quality ACH Network. A Terminated
Originator Database provides a mechanism for ODFIs to share information regarding the circumstances
under which ACH processing for specific Originators or Third-Party Senders has been terminated, thus
enabling ODFIs to focus due diligence efforts on Originators and Third-Party Senders whose history may
warrant further review. A Terminated Originator Database can provide an additional tool for ODFIs to
use to supplement their current processes and procedures for evaluating new Originators and Third-Party
Senders and for ongoing monitoring of Originators and Third-Party Senders. In addition, because the
utility of a Terminated Originator Database for all ODFIs grows exponentially with the number of ODFIs
contributing to the Database, the Board of Directors is recommending that ODFIs use NACHA’s preferred
Terminated Originator Database provider. While ODFIs are free to choose the Database or Databases that
they use and to which they contribute, the more institutions that use the preferred Terminated Originator
Database provider, the more useful it will be for each participating ODFI.

This policy is effective March 1, 2011. The Board of Directors encourages ODFIs to use a Terminated
Originator Database in the following ways: 1) ODFIs that have terminated an Originator or Third-Party
Sender for cause should populate the Database with information from their experiences, 2) to help focus
their diligence processes, ODFIs should access the Database prior to onboarding new Originators and
Third-Party Senders to learn about other ODFIs’ experiences with this company, and 3) ODFIs should
periodically check the Database for their current Originators and Third-Party Senders as these entities
might be originating through multiple ODFIs and termination by another ODFI may be indicative of
issues worthy of further review.

TERMINATED ORIGINATOR DATABASE AS A RISK MANAGEMENT TOOL

While ODFIs may individually use good risk management tools to evaluate new ACH origination clients,
ODFIs may be unaware of an Originator’s or Third-Party Sender’s past relationships with other ODFIs. Use
of a Terminated Originator Database will allow ODFIs to gain the benefit of other financial institutions’
experiences. This tool will reduce the likelihood that low quality Originators and Third-Party Senders can
mask problems from a potential new ODFI and easily be able to move from ODFI to ODFI.

Nonetheless, the Terminated Originator Database is not a list of prohibited or disapproved Originators
and Third-Party Senders. Each ODFI should utilize the information they obtain from the Database as part
of their effort to evaluate new and current Originator or Third-Party Sender customers. ODFIs should
independently perform due diligence to determine how this information will factor into their decision-
making and monitoring processes.

The value of a Terminated Originator Database is dependent on data being contributed by ODFIs of
all sizes and types. ODFIs should not only consult a Terminated Originator Database, but also should
contribute their own data in order to provide the most robust service for the benefit of all participating
ODFIs and the ACH Network. To enable the most effective information sharing in this regard, the Board

ORvi 2 0 1 3 O P E R AT I N G R U L E S
 N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

of Directors recommends a preferred Terminated Originator Database provider. ODFIs are free to choose
the Database(s) in which they participate, but ODFIs should consider, at a minimum, contributing to
and consulting the preferred Database in order to take advantage of the synergies provided by that
centralized facility.

POPULATION AND QUERY OF A TERMINATED ORIGINATOR DATABASE

ODFIs should utilize the Terminated Originator Database in the following ways:

• ODFIs that terminate an Originator or Third-Party Sender for cause should populate the Terminated
Originator Database with information that allows identification of the Originator or Third-Party
Sender to other ODFIs.

• ODFIs should access the Terminated Originator Database to learn about other ODFIs’ experiences
with Originators and Third-Party Senders. This information sharing will help ODFIs, as gatekeepers
to the Network, to have a more complete risk profile when determining whether or not to begin
origination for an Originator or Third-Party Sender.

• ODFIs should periodically access the Terminated Originator Database as part of their ongoing
monitoring efforts for current Originators and Third-Party Senders to determine whether termination
of other ODFI relationships raises issues warranting further review.

2 0 1 3 O P E R AT I N G R U L E S ORvii
N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

NACHA Board of Directors Policy Statement

on the Importance of Sound Business Practices
to Mitigate Corporate Account Takeover

The following Policy Statement on the Importance of Sound Business Practices to Mitigate Corporate
Account Takeover was adopted by the Board of Directors on October 21, 2010.

POLICY SUMMARY
Risks to payment networks are ever-changing. Cyber-thieves are becoming increasingly sophisticated at
exploiting vulnerabilities in corporate systems in order to commit fraud. Corporate Account Takeover, a
type of corporate identify theft in which cyber-thieves steal a business’ valid online banking credentials,
has recently been on the rise and represents a risk to ACH Network participants even though the roots
of this criminal activity are not in banking systems themselves. Accordingly, this policy statement of the
NACHA Board of Directors addresses the importance of Originating Depository Financial Institutions
(ODFIs) utilizing sound business practices to prevent and mitigate the risk of Corporate Account Takeover
within the ACH Network.

POLICY STATEMENT
Corporate Account Takeover is particularly pernicious because once a cyber-thief obtains a company’s
valid online banking credentials; the thief can use those credentials in a variety of ways. The thief may
initiate funds transfers out of the compromised business’ account by ACH or wire transfer to the bank
account of associates within the U.S. or directly overseas. In some cases, the perpetrator may also be
able to gain access to and review the business’ account details, such as account balances, activities and
patterns, enabling the perpetrator to mimic the legitimate users and initiate transactions undetected.

Cyber-thieves employ various methods to obtain access to the banking credentials from legitimate
businesses, including mimicking a legitimate institution’s website, using malware and viruses to
compromise the legitimate business’ system or even using social engineering to defraud employees into
revealing security credentials or other sensitive data. For example, corporate systems may be compromised
by (1) an infected document attached to an e-mail, (2) a link within an e-mail that connects to an infected
website, (3) employees visiting legitimate websites — especially social networking sites — and clicking
on the infected documents, videos or photos posted there, or (4) an employee using a flash drive that
was infected by another computer. In each case, the infected system is then exploited to obtain legitimate
security credentials that can be used to access a company’s corporate accounts.

ODFIs should vigilantly and proactively protect against this type of fraud in various ways, including
implementing systems designed to prevent and detect attempts to access a business’ banking credentials
and actual unauthorized access to the business’ banking accounts, and by keeping their own customers
informed about the importance of implementing their own systems and sound business practices to
protect themselves. Indeed, keeping customers informed of evolving risks can be an effective method to
combat cyber-thieves before they get access to the banking system. The types and significance of the risk
to each ODFI will vary depending on the financial institution, its business and its systems and processes.

It is essential that ODFIs and other ACH participants, such as Originators and Third-Party Senders, take
a risk-based approach tailored to their individual characteristics and their customers to avoid losses
and liability for themselves and other ACH participants. Accordingly, each ODFI should establish and
implement mechanisms aimed to prevent, detect and mitigate risk associated with Corporate Account
Takeover, and work with their customers to also take such a risk based approach — thus acknowledging

ORviii 2 0 1 3 O P E R AT I N G R U L E S
 N A C H A B O A R D O F D I R E C T O R S P O L I C Y S TAT E M E N T S

the important role of both the FI and the customer in preventing and detecting Corporate Account
Takeover. Each ODFI should periodically review and update such mechanisms and customer guidance
in response to developments in the methods used by cyber-thieves to perpetrate Corporate Account
Takeover and in the methods used to prevent, detect and mitigate risk associated with such fraud.

2 0 1 3 O P E R AT I N G R U L E S ORix
 F O R M A L R U L E S I N T E R P R E TAT I O N S

Formal Interpretations of the

NACHA Operating Rules

Proper Use of Standard Entry Class Codes

for Check Conversion Entries

SUMMARY
NACHA has been requested to issue a formal interpretation of the NACHA Operating Rules (Rules) with
respect to the practice of using the Prearranged Payment and Deposit (“PPD”) format for the conversion
and electronic collection of consumer checks collected at the point of purchase. This interpretation
clarifies that the POP entry and the BOC entry, and the POP Standard Entry Class and the BOC Standard
Entry Class (“SEC”) Codes, are the exclusive entry and class codes for ACH entries based on the conversion
of checks received at the point of purchase.1 The PPD entry and format may not be used for this purpose.

ISSUE
NACHA has been asked whether the practice of using a one-time PPD entry for the conversion of a check
received at the point of purchase rather than processing such a transaction as a POP entry (which was
specifically designed for electronic check conversion) is consistent with the Rules. NACHA understands
that under this practice a retailer receives a consumer’s check at the point of purchase and stamps
the back of the check with authorization language for an electronic debit. The consumer then signs
the authorization on the back of the check. The retailer later processes the check, captures the MICR
information from the check, and originates a PPD debit entry for the amount of the check. The retailer
may also provide the consumer with a copy of the authorization language on the consumer’s receipt or
on another document.

NACHA OPERATING RULES

POP Entries
A POP entry is defined as:

a Single Entry debit initiated by an Originator to an account of the Receiver based on an

Eligible Source Document provided to the Originator by the Receiver at the point-of-purchase
or manned bill payment location.2

A POP entry is initiated by an Originator based on a written authorization and account information
drawn from a check obtained from a consumer at the point of purchase. The check, which is voided by
the merchant and returned to the consumer at the point of purchase, is used to capture the consumer’s
routing number, account number, and check serial number, which are used to generate the ACH debit
entry to the consumer’s account.

1
The Rules for BOC entries were effective as of March 16, 2007.
2
2013 NACHA Operating Rules § 8.64 (“POP entry”)

2 0 1 3 O P E R AT I N G R U L E S ORxi
F O R M A L R U L E S I N T E R P R E TAT I O N S

POP entries are subject to special requirements under the Rules. For example, authorizations for POP
entries do not need to refer to an ability to revoke the entry, because revocation would not be practical
for POP transactions where the customer obtains the goods or services and then leaves the point of
purchase.3 In addition POP entries are subject to requirements as to the types of checks that can be
converted to POP entries,4 the capture of MICR information,5 and receipts.6 The Rules require that the
POP entry contain specific information, including, but not limited to, the Receiver’s bank routing number,
account number, serial number of the consumer’s source document, and location (city and state) of the
electronic terminal used for the transaction.7

BOC Entries8
A BOC entry is defined as:

a Single Entry debit initiated by an Originator to an account of a Receiver based on an Eligible

Source Document provided to the Originator by the Receiver at the point of purchase or at a
manned bill payment location for subsequent conversion during back-office processing.9

A BOC entry is initiated based on (1) notice posted at the point of purchase or manned bill payment
location, informing the Receiver that the check may be converted to an ACH transaction during back
office processing and collected electronically as an ACH debit, and (2) payment information (routing
number, account number, check serial number, and dollar amount of the transaction) obtained from a
check obtained from the Receiver at the point of purchase.

BOC entries are subject to special requirements under the Rules related to the types of checks that can
be converted10, notice and the provision of a copy of such notice language to the Receiver11, the capture
of MICR information12, verification of the identities of both Originator/Third-Party Sender and Receiver13,
documentation on Originators14, maintenance of a customer service telephone number15, and source
document copy, presentation, and secure storage requirements16. The Rules require that the BOC entry
contain specific information, including, but not limited to, the Receiver’s bank routing number, account
number, source document check serial number, and dollar amount of the check.

PPD Entries
A PPD Entry is defined as

a credit or debit Entry initiated by an Organization to a Consumer Account of a Receiver based

on a standing or a Single Entry authorization from the Receiver. 17

Prior to the origination of a PPD entry to the consumer’s account, the consumer must have authorized
the Originator to initiate the entry to such an account. This authorization must be in writing and signed
or similarly authenticated by the consumer, and the consumer must be provided with an electronic or
3
Id. at § 2.5.10.2
4
Id. at § 8.32
5
Id. at § 2.5.10.4
6
Id. at §2.5.10.5
7
Id. at Appendix Three, subpart 3.1.15
 8
Id. at § 8.11 (“BOC entry”)
 9
Id. at § 8.11
10
Id. at § 8.32
11
Id. at § 2.5.2.2
12
Id. at § 2.5.2.4
13
Id. at § 2.5.2.5
14
Id. at § 2.5.2.5
15
Id. at § 2.5.2.5
16
Id. at § 2.5.2.5
17
Id. at § 8.66

ORxii 2 0 1 3 O P E R AT I N G R U L E S
 F O R M A L R U L E S I N T E R P R E TAT I O N S

paper copy of the authorization. The authorization must be readily identifiable as an authorization
and must clearly and conspicuously state its terms, as well as indicate that the Receiver may revoke the
authorization by notifying the Originator in the manner specified in the authorization. The authorization
process must evidence both the consumer’s identity and his or her assent to the transaction. Further, the
Rules require that the PPD entry contain certain information, including, but not limited to, the Receiver’s
bank routing number and account number.18 In addition, the consumer must be provided an electronic
or paper copy of the authorization.19

Rules Analysis
The express language of the Rules strongly suggests that POP and BOC entries are intended to be the
exclusive entries and class codes for ACH entries based on the conversion of checks received at the
point of purchase. The special requirements for POP and BOC entries would be largely unnecessary
if the Rules were interpreted to provide for POP and BOC transactions to be conducted as PPD entries
without compliance with POP and BOC requirements. Nevertheless, it could be argued that the fact
that the definition of PPD entry excludes MTE and POS entries, but does not exclude POP and BOC
entries, means that some, or all, transactions that meet the definition of POP and BOC entries may also
be processed as PPD entries. Similarly, it could be argued that because, for example, the rules for POP
and BOC entries do not require the Originator to provide the Receiver with a copy of the authorization
at the point of sale, the requirements of POP and BOC entries and PPD entries are alternative ways of
accomplishing the same general type of transaction.

Because the express language of the Rules does not conclusively resolve whether or not POP and BOC
entries are the exclusive means of conducting certain transactions, NACHA is issuing this interpretation
under Section 1.3.3 of the Rules.

Interpretation
NACHA intended the rules for POP entries to be the exclusive entry and class code for ACH entries
based on the conversion of checks received at the point of purchase. Recognizing the importance
of providing a legal framework within the Rules that would protect ACH participants with regard to
the initiation of point-of-purchase entries, in March 1999, the NACHA Voting Membership approved an
interim rule designed to expand the definition of the PPD entry format to allow its use in initiating one-
time ACH debit entries for purchases made at the point of purchase. This interim rule was, however,
only intended to be a one-year interim rule to permit the implementation of a newly created Standard
Entry Class Code for point of purchase transactions-the POP entry. Subsequently, in September 2000,
the POP SEC Code and the requirements for POP entries became effective and superseded the use of the
PPD interim rule for point-of-purchase entries.20 As of March 16, 2007, an additional application (BOC)
for the conversion of checks presented at the point of purchase was adopted with a legal framework
and technical requirements designed to protect ACH participants with regard to the initiation of check
conversion entries.

The rules for POP and BOC entries establish the legal framework and requirements that the NACHA
Voting Membership determined were needed to protect ACH participants with respect to check conversion
transactions initiated at the point of purchase. The rules for POP and BOC entries also establish requirements
for the provision of information on the Receiver’s bank account statement to enable the Receiver to
identify the converted check and the location where the payment was made. The POP and BOC
applications were specifically designed to provide Receiver protections and requirements unique to this
type of conversion activity.

18
Id. at Appendix Three, subpart 3.1.17
19
Id. at § 2.3.2.2
20
2000 NACHA Operating Rules, page R2

2 0 1 3 O P E R AT I N G R U L E S ORxiii
F O R M A L R U L E S I N T E R P R E TAT I O N S

These unique requirements were intended to mitigate risk and reduce customer service problems. These
requirements do not apply to PPD entries and therefore the use of PPD entries for conversion of checks
received at the point of sale could result in more risk to ACH participants and customer service issues.
For example, the PPD format cannot accommodate the inclusion of the check serial number from the
Receiver’s source document. Similarly, the rules for PPD entries do not require the placement of this
information on the Receiver’s bank account statement.

CONCLUSION
The practice of receiving checks at the point of purchase and then converting those checks to one-time
PPD entries is inconsistent with the exclusive application of POP entries to such payments under the
Rules. The rules for POP entries and the POP SEC Code and BOC entries and the BOC SEC Code are the
only rules, and the only SEC Codes, that provide for the conversion of checks received in-person. The
use of any other SEC Codes for this purpose is not permissible under the Rules.

ORxiv 2 0 1 3 O P E R AT I N G R U L E S
 F O R M A L R U L E S I N T E R P R E TAT I O N S

Proper Use of SEC Codes;

Aggregation of Transactions

SUMMARY
This formal interpretation of the NACHA Rules addresses (i) when it is appropriate to aggregate transactions
into a single ACH entry, (ii) what is the most appropriate SEC code to use for specific transaction types
given the method used to obtain consumer authorization, the manner in which an ACH product is used by
the consumer and the information needed by RDFIs and NACHA to manage risk and, in the case of RDFIs,
to manage customer relationships, and (iii) what party should be identified in the “Company Name”
field of the ACH entry. The NACHA Board has determined that (i) transactions may not be aggregated
under the POS or MTE codes, but may be aggregated under the WEB or PPD codes if the transactions
are accumulated for more than fourteen (14) days, (ii) if either the POS or MTE code may apply to a
transaction that otherwise could be characterized as WEB or PPD (including when a Receiver uses his
or her mobile device to initiate a transaction at the point-of-sale), the POS or MTE code, respectively,
must be used, and (iii) the payee of the underlying transaction being settled through the ACH should
be identified in the “Company Name” field. This interpretation does not address the accumulation by
a single merchant of multiple purchases at that merchant (e.g., weekly billing of music purchases at an
internet music site). That is a separate issue that will be separately considered by NACHA.

ISSUE
Some providers of ACH services seek to aggregate transactions that occur during a single day, or over
multiple days, into a single ACH entry. This aggregation may be attempted across multiple merchants
and multiple transactions types (e.g., transactions at retail locations might be combined with ATM
withdrawals). Accordingly, the issue has arisen whether such aggregation is permissible under the Rules,
and if so, how such transactions should be handled within the existing Rules. As a corollary, if more
than one of the POS, MTE, WEB or PPD codes arguably might apply on their face, which code should be
used in which circumstances? Moreover, since the payee of such transactions may be different from the
Originator who obtains the Recipient’s authorization, which name should be included in the “Company
Name” field of the ACH message?

INTERPRETATION
The NACHA Rules do not permit aggregation of transactions under the POS or MTE codes. Each time an
ACH-linked card or other similar ACH service that can be used at multiple payees is used by a consumer
at an electronic terminal in a retail location in the case of the POS code, or at an ATM in the case of the
MTE code, the ODFI must submit a separate ACH entry that is properly formatted using the POS or MTE
SEC codes, respectively. Multiple transactions at one or more electronic terminals may not be aggregated
in a single POS or MTE entry.

Transactions may be aggregated under the WEB or PPD codes only in the following circumstances. The
PPD code may be used for a properly authorized ACH transaction that represents a single payment on a
separate account regardless of whether there have been multiple charges by the consumer to that account
(i.e., for a bill payment), provided that each such payment on account covers at least fourteen (14) days of
transactions. If the original enrollment for an ACH service was performed on the internet, the WEB code
may be used for a properly authorized ACH transaction that represents a single payment on a separate
account regardless of whether there have been multiple charges by the consumer to that account (i.e.,
for a bill payment), provided that each such payment on account covers at least fourteen (14) days of
transactions. This fourteen (14) day window provides a clear dividing line between payments on an

2 0 1 3 O P E R AT I N G R U L E S ORxv
F O R M A L R U L E S I N T E R P R E TAT I O N S

account, such as monthly bill payments (e.g., the monthly payment of a charge card bill), and transactions
that are effectively pass-through debits to a deposit account at an RDFI.

If a consumer has an account that ordinarily is billed in periods of more than fourteen (14) days, and
the consumer separately authorizes an individual payment on account for a period of less than fourteen
days (for example, by logging on to the biller’s website to make an individual interim payment prior to
the close of a monthly billing cycle), the ODFI may process such transaction as a single PPD or WEB
transaction, depending on whether the original enrollment for the ACH service was obtained on the
internet. A separate authorization of payment in this context must be a specific authorization of the
specific total amount to be debited at that time, and a separate specific authorization must be obtained
from the consumer each time another payment of fourteen (14) days or less is made. For clarity, the use
of a debit card at the point-of-sale does not constitute a separate specific authorization for this purpose.

Furthermore, the SEC Code Allocation Chart attached hereto provides guidance on the appropriate SEC
Code to use in connection with transactions based on how an ACH service is being used and how the
original authorization for that service was obtained. For example, if an Originator provides a debit card
to consumers that can be used for a variety of transactions pursuant to a written, standing authorization
to debit the amount of those transactions to a deposit account at an RDFI, the transactions should be
handled as follows: Each use of the debit card at a point-of-sale terminal should be treated as a separate
POS transaction; each use of the debit card at an ATM should be treated as an MTE transaction; and
each use of the debit card to make purchases on the internet should be treated as a PPD transaction. By
contrast, if the Originator obtains the consumer’s original standing authorization for the same product via
the internet, the transactions should be handled as follows: Each use of the debit card at a point-of-sale
terminal still should be treated as a separate POS transaction; each use of the debit card at an ATM still
should be treated as an MTE transaction; but each use of the debit card to make purchases on the internet
should be treated as a WEB transaction. As indicated above, the Originator may not aggregate multiple
transactions across multiple payees. However, if the “account” offered by Originator is only billed to the
consumer for periods of more than fourteen (14) days, then those transactions may be processed as a
single bill payment transaction under the PPD or WEB code, respectively, for the total amount owing at
the end of such period.

Finally, in order to provide appropriate information to the RDFI and NACHA, the party identified in the
“Company Name” field of the ACH Entry in each of these cases should be the party to which the funds
ultimately will be transferred. For example, in the card product above, the ultimate payee is the merchant
or owner of the ATM where the card is used, not the Originator that issues the card. Similarly, in a bill
payment service, the ultimate payee is the biller, not the provider of the bill payment service.

EXPLANATION OF SEC CODE ALLOCATIONS

The following articulates the basis for the allocations set forth in the SEC Code Allocation Chart (“Chart”)
that accompanies the Proper Use of SEC Codes; Aggregation of Transactions Rules Interpretation
(“Interpretation”). As noted, the Chart addresses only products that can be used on a recurring basis
rather than individual entry transactions, which are not at issue in this Interpretation.

The first row of the Chart addresses products that are physically used at the point-of-sale for retail
purchases. Box A addresses products for which both enrollment and use occurs at the point-of-sale. This
is the quintessential transaction for which the POS code was originally developed.

Box B addresses products for which the original enrollment occurred on the internet, but which are then
used at the physical point-of-sale. The Interpretation requires that such transactions be treated as POS
because this more specific SEC code is more closely related to the nature of the transaction being initiated
by the consumer at the time of use of the card. As noted above, use of this code results in the delivery

ORxvi 2 0 1 3 O P E R AT I N G R U L E S
 F O R M A L R U L E S I N T E R P R E TAT I O N S

of appropriate information to RDFIs to enable risk management and customer service, and also enables
NACHA to more effectively conduct its risk management services for the ACH Network. Accordingly,
the POS code should be used when a Receiver uses his or her mobile device enabled with near-field
communication or similar technologies to authorize Entries at the point-of-sale, even if the WEB code also
could technically apply.

Box C addresses products for which enrollment occurred over the telephone, e.g., via the entry of a code
through a VRU, but which are then used at the physical point-of-sale. As with the other boxes in this row,
the POS code is the most directly relevant code, enabling the communication of the individual transaction
data to the RDFI.

Boxes D, E and F address ACH products that are used on the internet. When an ODFI (or Originator)
has a pre-existing standing authorization obtained through another channel (e.g., a physically signed
authorization for insurance payments), the fact that the customer later uses the ODFI’s or Originator’s
internet service to confirm an individual payment does not require conversion of the transaction to a WEB
code. Many of the risks associated with internet-based transmission of the original account information
are not present in such circumstances.

Boxes G, H and I address the use of ACH products at the ATM, and raise issues very similar to the boxes
in the first row of the chart. In short, in order to manage risks associated with access to their accounts at
ATMs, RDFIs need to have the information communicated through the MTE transaction code, regardless
of how the consumer originally enrolled in the service.

Boxes J, K and L address the authorization of ACH transactions over the phone pursuant to a previously
obtained standing ACH authorization or a one-time confirmation of a previously provided written
authorization form.

Similarly, the final row of the chart addresses recurring debits for which enrollment occurred via hard
copy, via the internet or via the telephone. As with the preceding row, the appropriate codes for
transactions relying on hard copy or internet enrollment (including VRU-based acceptance of a hard copy
authorization form) are the general codes that apply based on the form of enrollment for the service —
WEB for internet-based enrollment, and PPD for all others. If the Originator complies with the Rules
for origination of recurring TEL transactions in connection to a telephone-based authorization (including
recorded phone line and written confirmation), the TEL code applies.

2 0 1 3 O P E R AT I N G R U L E S ORxvii
F O R M A L R U L E S I N T E R P R E TAT I O N S

NACHA SEC CODE GUIDANCE FOR RECURRING OR MULTIPLE DEBITS

TRANSACTION ENROLLMENT/AUTHORIZATION METHOD

INITIATION
METHOD PHYSICAL ENROLLMENT INTERNET ENROLLMENT TELEPHONE ENROLLMENT
Use at Point-of-Sale Example: Example: Example:
Customer enrolls at a merchant store, Customer enrolls at a merchant or bank Customer enrolls through a merchant
a bank branch or in response to a mail web site for an ACH-based debit card, or bank telephone system for an
solicitation for an ACH-based debit card, and uses the card at a POS terminal ACH-based debit card, and uses the
and uses the card at a POS terminal Customer enrolls via a mobile card at a POS terminal
Proper SEC Code: POS device for an ACH-based near-field Proper SEC Code: POS
communication debit service on the
device, and uses the mobile device at a
POS terminal
Proper SEC Code: POS
Box A Box B Box C
Use on the Internet Example: Example: Example:
Customer opens account at a bank Customer executes at a bank’s web site Customer enrolls through a biller’s or
branch and authorizes debits to transfer an authorization to transfer funds into service provider’s telephone system
funds into the account, and initiates a savings account, and initiates each to pay bills, and initiates individual
such debits via the bank’s web site transfer via the bank’s web site bill payments at the biller’s or service
Customer enrolls in biller’s or service Customer enrolls at a biller’s or service provider’s web site
provider’s bill payment service via mail, provider’s web site to pay bills, and Customer enrolls through a merchant
and initiates individual bill payments at initiates individual bill payments at the or bank telephone system for an
the biller’s or service provider’s web site web site ACH-based debit card, and uses the
Customer enrolls at a merchant store, Customer enrolls at a merchant or bank card to make a purchase at a web site
a bank branch or in response to a mail website for an ACH-based debit card, Proper SEC Code: PPD
solicitation for an ACH-based debit card, and uses the card to make a purchase
and uses the card to make a purchase at a web site
at a web site Customer enrolls via a mobile device in
Proper SEC Code: PPD his/her biller’s mobile bill presentment
and payment service, and initiates
individual bill payments via the mobile
device
Proper SEC Code: WEB
Box D Box E Box F
Use at ATM Example: Example: Example:
Customer enrolls at a merchant store, Customer enrolls at a merchant or Customer enrolls through a merchant
a bank branch or in response to a mail bank web site for an ACH-based debit or bank telephone system for an
solicitation for an ACH-based debit card, and uses the card at an ATM to ACH-based debit card, and uses the
card, and uses the card at an ATM to withdraw cash card at an ATM to withdraw cash
withdraw cash Proper SEC Code: MTE Proper SEC Code: MTE
Proper SEC Code: MTE
Box G Box H Box I

ORxviii 2 0 1 3 O P E R AT I N G R U L E S
 F O R M A L R U L E S I N T E R P R E TAT I O N S

TRANSACTION ENROLLMENT/AUTHORIZATION METHOD

INITIATION
METHOD PHYSICAL ENROLLMENT INTERNET ENROLLMENT TELEPHONE ENROLLMENT
Use via Telephone Example: Example: Example:
Customer opens account at a bank Customer executes at a bank’s web Customer receives a written ACH
branch and authorizes debits to transfer site an authorization to transfer funds authorization with a billing statement
funds into the account, and initiates into a savings account, and initiates and “signs” the authorization to pay
such debits via the bank’s telephone each transfer via the bank’s telephone the bill by entering a code into the
system system biller’s VRU
Customer enrolls in biller’s or service Customer enrolls on a biller’s or service Proper SEC Code: PPD
provider’s bill payment service via mail, provider’s web site to pay bills, and
and initiates individual bill payments initiates individual bill payments via the
through the biller’s or service provider’s biller’s or service provider’s telephone
telephone system system
Customer enrolls at a merchant store Customer enrolls on a merchant or
or a bank branch for an ACH-based bank website for an ACH-based debit
debit card, and uses the card to make a card, and uses the card to make a
purchase over the phone purchase over the phone
Proper SEC Code: PPD Proper SEC Code: WEB
Box J Box K Box L
Use via Example: Example: Example:
Pre-Authorization Customer executes in person or via mail Customer executes at a biller’s web Customer receives a written ACH
(i.e., no other direct a written authorization for a monthly site an authorization for a monthly ACH authorization with a billing statement
action) ACH debit to pay a bill debit to pay a bill and “signs” the authorization to pay
Customer executes in person or via Customer executes at a bank’s web site the bill and future recurring bills by
mail a written authorization for a an authorization for a monthly transfer entering a code into the biller’s VRU
monthly ACH debit to transfer funds into into a savings account Proper SEC Code: PPD
another account Proper SEC Code: WEB Customer calls into a recorded biller
Proper SEC Code: PPD customer service line and orally
authorizes monthly debits; the biller
complies with the Rules for recurring
TEL transactions and timely mails a
written copy of the authorization
Proper SEC Code: TEL
Box M Box N Box O

2 0 1 3 O P E R AT I N G R U L E S ORxix
N E T W O R K A D M I N I S T R AT I O N F E E S

Network Administration Fees

The NACHA Operating Rules require each Participating Depository Financial Institution that transmits
or receives ACH entries (commercial and Federal Government) to pay an annual fee and a per-entry fee
to pay for costs associated with the administration of the ACH Network. These Network Administration
Fees apply to all entries subject to the requirements of the NACHA Operating Rules, whether such entries
are transmitted via an ACH Operator, sent directly from one Participating DFI to another, or sent through
another entity. The Network Administration Fees have been established by the NACHA Board of Directors
and are reviewed and modified, as appropriate, on an annual basis.

NETWORK ADMINISTRATION FEES AND DATA REPORTING REQUIREMENTS

The accompanying chart provides information on the amount of the annual and per-entry fees for the
2013 calendar year. The ACH Operators collect the annual fees and per-entry fees on behalf of NACHA
for entries sent from one Participating DFI to another Participating DFI through the ACH Operators.

Financial institutions are required to report and NACHA collects directly the per-entry fees for ACH entries
not sent through the ACH Operators, but that are sent as part of direct send or “on-we” arrangements. A
direct send or “on-we” arrangement is one in which a Participating DFI sends a payment file that uses the
NACHA formats and/or is covered by the NACHA Operating Rules, where that file is not processed by an
ACH Operator, but instead is exchanged with another non-affiliated Participating DFI, either directly or
through another entity. This definition applies regardless of how interbank settlement is accomplished.

Participating DFIs with direct send or “on-we” volume exceeding 5 million entries annually are obligated
to file the requisite reporting with NACHA quarterly. Participating DFIs with direct send volume below
this threshold are obligated to file with NACHA annually. These financial institutions are required to
submit transaction volume data and any associated fees directly to NACHA using Form N-7 (2013).
Any Participating DFI whose direct send or “on we” volume of entries originated or received exceeds
5 million for any quarter ending March 31, June 30, September 30, or December 31, 2013 must submit
the above data and fees on a quarterly basis thereafter. The submission deadlines for quarterly filers are
April 30, July 31, and October 31, 2013, and January 31, 2014. Participating DFIs that exceed the threshold
during the calendar year must aggregate all prior quarters’ fees in their current quarter’s Form N-7 (2013)
payment. Participating DFIs whose direct send volume is below this threshold must submit the above
data and fees for calendar year 2013 by January 31, 2014.

National Automated Clearing House Association

2013 Schedule Of Fees

ACH Network Administration Fees

This Schedule of Fees has been established by the NACHA Board of Directors for calendar year 2013
in accordance with the requirements of the NACHA Operating Rules, Article One (General Rules),
Section 1.10 (Network Administration Fees).

• Per-Entry Fee ( January 1–December 31) . . . . . . . . . . $ .000145

• Annual Fee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . $ 144.00

ORxx 2 0 1 3 O P E R AT I N G R U L E S
 N E T W O R K A D M I N I S T R AT I O N F E E S

NETWORK ADMINISTRATION FEES — FILING REQUIREMENTS FOR

PARTICIPATING DEPOSITORY FINANCIAL INSTITUTIONS
Form N-7 (2013) is provided for the purposes of reporting and submitting payment of Network
Administration Fees, as required by the NACHA Operating Rules, on ACH entries that are transmitted or
received under a direct send or “on-we” arrangement. These reporting requirements are not applicable to
Participating DFIs whose entries are processed exclusively through an ACH Operator, where all applicable
transaction volume will be reported to and fees collected by the ACH Operators on behalf of NACHA.

Who Must File

Any Participating DFI that transmits or receives entries that use the NACHA formats and/or are covered by
the NACHA Operating Rules, where those entries are not processed by an ACH Operator, but instead are
exchanged with another non-affiliated Participating DFI, either directly or through another entity, during
the 2013 calendar year.

Who Does Not Have to File

Any Participating DFI that transmits and receives 100% of its ACH entries during 2013 through an ACH
Operator or with affiliated Participating DFIs does not need to file Form N-7 (2013). All applicable
Network Administration Fees are billed and collected on NACHA’s behalf by the ACH Operator, and
appear on your customer statement as “NACHA Admin Network Fee/Entry” and “NACHA Admin Network
Fee/Month.”

When and Where to File

Any Participating DFI whose direct send or “on-we” volume of entries originated and received exceeds
5 million for any quarter ending March 31, June 30, September 30, or December 31, 2013 must file on
a quarterly basis thereafter. The submission deadlines for quarterly filers are April 30, July 31, and
October 31, 2013, and January 31, 2014. Participating DFIs that exceed this threshold during the calendar
year must aggregate all prior quarters’ fees in the current quarter’s payment. Participating DFIs whose
direct send or “on-we” volume is below the threshold must submit their calendar year 2013 data and fees
by January 31, 2014.

Completed forms and payment must be received by NACHA no later than the above deadlines and should
be mailed to: NACHA – The Electronic Payments Association, Attn: Finance Department, 13450 Sunrise
Valley Drive, Suite 100, Herndon, VA 20171. Payment may be made by ACH credit or check (made
payable to NACHA).

To pay by ACH credit, credit must be initiated by the organization filing Form N-7. UPIC Routing & Transit
# 021052053, Acct # 59058945. Use CCD format for single filing. Complete in Batch Header (1) Company
Name (2) Company Entry Description (specify Form N-7 (2013)).

Form Instructions
Line 1.  Enter legal name of Participating DFI.

Line 2.  Enter mailing address of Participating DFI.

Line 3a.  List the number of ACH entries transmitted and received by the Participating DFI that were not
processed by an ACH Operator but were exchanged with another non-affiliated Participating
DFI, either directly or through another entity, for the applicable period. Entries should be sorted
by routing number of the non-affiliated DFI and include debits, credits and entries of non-value.
If there are more routing numbers than spaces available, attach another sheet. Total columns and
add together to calculate the grand total.

2 0 1 3 O P E R AT I N G R U L E S ORxxi
N E T W O R K A D M I N I S T R AT I O N F E E S

Line 3b.  Enter the grand total from line 3a.

Line 4.  Represents the 2013 per entry fee of $.000145

Line 5.  Multiply line 3b by line 4 [example: (line 3b) 100,000 x (line 4) $.000145 = (line 5) $14.50]

Line 6. Payment due is equal to the amount on line 5. Indicate payment method. If by check, make
check payable to NACHA. If payment by ACH Credit, indicate date of credit to be initiated by
the business. See account information above for ACH Credit. If amount on line 5 is less than one
dollar, submit the completed form only; no payment is due.

Still Need Additional Information?

Downloadable Forms and Instructions are available at http://www.nacha.org/c/Ntwrkadminfee.cfm or
contact Member Services, 800-487-9180 or 703-561-1100 or email: [email protected].

ORxxii 2 0 1 3 O P E R AT I N G R U L E S
 N E T W O R K A D M I N I S T R AT I O N F E E S

FORM N-7 (2013)

Select Filing Period and Deadline (check all that apply):

Period Filing Deadline

For annual filers: o  December 31, 2013 January 31, 2014

For quarterly filers: o  March 31, 2013 April 30, 2013

o  June 30, 2013 July 31, 2013
o  September 30, 2013 October 31, 2013
o  December 31, 2013 January 31, 2014

1. Financial Institution Name____________________________________________________________________________

2. Business Address____________________________________________________________________________________
____________________________________________________________________________________________________

____________________________________________________________________________________________________

3. Direct Send Information

a. 2013 direct send ACH entries by routing number of non-affiliated Participating DFI (see instructions)

DIRECT SEND DETAIL

ROUTING NUMBER ENTRIES RECEIVED ENTRIES ORIGINATED

TOTALS

GRAND TOTAL (TOTAL RECEIVED + TOTAL ORIGINATED)

2 0 1 3 O P E R AT I N G R U L E S ORxxiii
N E T W O R K A D M I N I S T R AT I O N F E E S

FORM N-7 (2013)

(continued)

b. 2013 total direct send ACH entries (see instructions) ___________________________________

4. 2013 per entry fee x  $.000145

5. Uncollected 2013 Network Administrative Fees (line 3 x line 4) $__________________________________

6. Payment Due: (Amount on line 5)  Check enclosed _______________   or  Date of ACH credit _______________
(If less than $1.00, no payment due, submit form only)

I declare that I have examined this form and to the best of my knowledge and belief, it is true, correct
and complete.

Signature_______________________________________________________________________ Date____________________

Printed Name___________________________________________________________________________________________

Title____________________________________________________________________________________________________

Financial Institution Name________________________________________________________________________________

Email Address______________________________________________ Phone Number_______________________________

Mail completed form and payment to:

 ACHA – The Electronic Payments Association

N
Attn: Finance Department
13450 Sunrise Valley Drive, Suite 100
Herndon, VA 20171

ORxxiv 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Revisions to the NACHA Operating Rules

& Guidelines

The 2013 edition of the NACHA Operating Rules & Guidelines contains changes related to four sets
of amendments: IAT Modifications and Refinements; Data Passing; ODFI Return Rate Reporting; and
Incomplete Transactions and the Return of Funding Debit Entries. The effective date for these changes is
March 15, 2013.

This section also includes a technical summary of all changes to the Rules that were implemented in
2012. The text changes were officially communicated via Supplements, but they are summarized here
for reference. Please note that since these changes are already effective, they are not marked within the
text of the Rules.

2 0 1 3 O P E R AT I N G R U L E S ORxxv
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

IAT Modifications and Refinements

(Approved September 8, 2011 – Effective March 15, 2013)

SUMMARY
The IAT Modifications and Refinements changes clarify and enhance the Rules where appropriate to
support more efficient processing of IAT Entries.

KEY COMPONENTS OF RULE AMENDMENTS

Use of Return Reason Code R16 to Identify OFAC-Related Returns
This amendment revises the description of R16 (Account Frozen) to accommodate the return of Entries
in response to an instruction from OFAC to do so.

Since implementing IAT, NACHA has received inquiries regarding which return reason code is appropriate
for an RDFI to use to indicate that the return of an IAT Entry was based on an instruction to do so from
OFAC. Under the current Rules, R16 (Account Frozen) provides the closest match, permitting an RDFI to
return an Entry because access to the account is restricted due to specific action taken by the RDFI or
by legal action. This amendment expands the title and description of Return Reason Code R16 (Account
Frozen) to accommodate this code’s use for the RDFI’s return of an Entry based on an instruction from
OFAC.

Return Reason Code and Change Code for Gateway Use with Incorrectly-Coded International Payments
This amendment establishes two new codes – one Return Reason Code and one Change Code – for use
by Gateways to advise ODFIs and Originators that funds related to a domestically-coded Entry (i.e., PPD,
CCD, etc.) are being moved out of the country and that the Entry should have been formatted as an IAT
Entry.

This change defines an additional Return Reason Code for use by Gateways that clearly indicates that
an Entry is being returned because it is part of an international payment transaction and lacks sufficient
information for the Gateway to ensure that it complies with U.S. law. This rule also creates a new NOC
code, to be used only by a Gateway, to notify the Originator/ODFI that the payment has been processed
but that it is part of an international payment transaction and requires appropriate formatting going
forward.

These new codes enable the Gateway to process or return the payment, depending on its risk tolerance,
while conveying critical payment information back to the ODFI.

Corrected Data for IAT Entries – NOC Code Descriptions

This amendment corrects the descriptions of Change Codes C04 (Incorrect Individual Name/Receiving
Company Name) and C09 (Incorrect Individual Identification Number) as they relate to IAT Entries.
Specifically, this change revises IAT information under the “Notes” section for these codes to reflect the
proper field lengths for these data elements as they are used within the Corrected Data Field of an IAT
Entry. (Note: These changes have no impact on NOC record layouts or formatting.)

This amendment also modifies the title of Change Code C09 to adopt the corresponding field name for
IAT Entries.

ORxxvi 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

TECHNICAL SUMMARY
The changes to the Rules language, as noted below, represent modifications to the NACHA Operating
Rules.

Use of Return Reason Code R16 to Identify OFAC-Related Returns

• Appendix Four, Part 4.2 (Table of Return Codes): R16 (Account Frozen/Returned per OFAC Request) –
revises the description to clarify that this return code can be used with an OFAC instruction for return.

Return Reason Code and Change Code for Gateway Use with Incorrectly-Coded International Payments
• Appendix Four, Part 4.2 (Table of Return Codes): R85 (Incorrectly Coded Outbound International
Payment) – establishes a new return code for an incorrectly-coded outbound international payment.

• Appendix Five, Part 5.3 (Table of Change Codes for Notification of Change): C14 (Incorrect SEC Code
for Outbound International ACH Transaction) - establishes a new change code for an incorrectly-
coded outbound international payment.

Corrected Data for IAT Entries – NOC Code Descriptions

• Appendix Five, Part 5.3 (Table of Change Codes for Notification of Change)

- C04 (Incorrect Individual Name/Receiving company name) – clarifies the description as it relates
to IAT Entries.

- C09 (Incorrect Individual Identification Number) – clarifies the description as it relates to IAT
Entries

2 0 1 3 O P E R AT I N G R U L E S ORxxvii
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Data Passing

(Approved April 2, 2012 – Effective March 15, 2013)

SUMMARY
The Data Passing Rule prohibits sharing of certain customer information by Originators, Third-Party
Service Providers and ODFIs for the purpose of initiating debit Entries that are not covered by the original
authorization.

KEY COMPONENTS OF RULE AMENDMENT

This amendment revises the Rules to: 1) prohibit an ODFI from disclosing a consumer Receiver’s account
number or routing number to any third party for use in initiating a debit Entry that is not part of the
original authorization; and 2) require the ODFI to ensure that the Originator and any Third-Party Service
Provider do not disclose such information for use in initiating a debit Entry that is not part of the original
authorization.

IMPACT TO PARTICIPANTS
Receivers: The rule is expected to benefit consumer Receivers by protecting their account information
from use in connection with purported authorizations that they do not intend to give.

RDFIs: The rule is expected to reduce RDFIs’ exception processing associated with unauthorized
transactions and other customer service costs due to questionable transactions.

ODFIs, Originators and Third-Party Service Providers: The rule should have little or no effect on ODFIs,
Originators, and Third-Party Service Providers, since most data passing activity is prohibited by The
Restore Online Shoppers’ Confidence Act.

TECHNICAL SUMMARY
Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the
Rules that are affected by this amendment are also included.

 rticle Two, Subsection 2.3.4 (Restrictions on Data Passing) – Adds a new subsection to the Rules
• A
on authorization that:

(1) prohibits an ODFI from disclosing the Receiver’s account number or routing number to any
third party for such third party’s use, directly or indirectly, in initiating a debit Entry that is not
covered by the original authorization; and

(2) requires an ODFI to ensure that the Originator and any Third-Party Service Provider acting
on behalf of the Originator or ODFI do not disclose the Receiver’s account number or routing
number to any third party for such third party’s use, directly or indirectly, in initiating a debit
Entry that is not covered by the original authorization.

ORxxviii 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

ODFI Return Rate Reporting

(Approved April 2, 2012 – Effective March 15, 2013)

SUMMARY
The modification to the Rules for ODFI Return Rate Reporting will reduce the reporting period from
60 days to 30 days during which the ODFI has to reduce a return rate below the threshold before the
initiation of a rules enforcement proceeding.

KEY COMPONENT OF RULE AMENDMENT

This amendment will reduce the ODFI Return Rate Reporting period from 60 days to 30 days.

IMPACT TO PARTICIPANTS
All Participants: By shortening the deadline by which an excessive rate of return must be resolved by
an ODFI and its Originator, the ACH Network, as a whole, benefits through the introduction of fewer
unauthorized debits into the payments system.

RDFIs: RDFIs should receive fewer unauthorized entries, resulting in lower exception processing costs
associated with the return of unauthorized entries and the response to customer service calls.

ODFIs: Some ODFIs, particularly those with inadequate risk management procedures, may incur
incremental costs associated with development and implementation of additional policies and procedures
to ensure their Originators’ and Third Party Senders’ compliance with the shortened grace period.

Originators and Third-Party Senders: Originators and Third-Party Senders with excessive return rates
will be compelled by their ODFIs to take action more quickly to reduce their return rates and will likely
incur costs in doing so.

TECHNICAL SUMMARY
The changes to the Rules language, as noted below, represent modifications to the NACHA Operating
Rules.

• Article Two, Subsection 2.17.2.1 (Additional ODFI Action and Reporting When the Return Threshold
is Exceeded) and Article Two, Subsection 2.17.2.2 (ODFI Reduction of Return Rate) – Reduces to
30 days from 60 days the time period during which an ODFI may reduce a return rate below the
applicable threshold before a rules enforcement proceeding may be initiated.

• Appendix Ten, Subpart 10.2.2 (National Association Action on Receipt of Information Reported by
ODFI) – Reduces the 60 day time period to 30 days before NACHA may initiate a rules enforcement
proceeding against an ODFI when an Originator’s or Third-Party Sender’s unauthorized Entry return
rate exceeds the threshold.

• 
Appendix Ten, Subpart 10.4.3 (Submission Requirements for Rules Enforcement Proceedings
Initiated by the National Association) and Appendix Ten, Subpart 10.4.7.4 (Class 2 Rules Violation)
– Reduces to 30 days the time period during which an ODFI may reduce a return rate below the
applicable threshold before a rules enforcement proceeding may be initiated.

• Appendix Ten, Subpart 10.4.7.4 (Class 2 Rules Violation) - Revises the reference for the ODFI action
time frame from 60 days to 30 days.

2 0 1 3 O P E R AT I N G R U L E S ORxxix
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Incomplete Transactions and the Return of Funding Debit Entries

(Approved April 2, 2012 – Effective March 15, 2013)

SUMMARY
The Incomplete Transactions and the Return of Funding Debit Entries rule allows the return of a debit
Entry to a Consumer Account within 60 days of the Settlement Date for an “Incomplete Transaction.”

KEY COMPONENT OF RULE AMENDMENT

This rule allows the return of a debit Entry to a Consumer Account within 60 days of the Settlement Date
for an “Incomplete Transaction.” An “Incomplete Transaction” is defined as a transaction for which a Third
Party Sender debits a consumer’s account to collect funds, but does not complete the corresponding
payment to the party to which payment is owed. The request for recredit and the RDFI’s return of a debit
entry related to an Incomplete Transaction will be subject to the same requirements and time frames
currently defined within the Rules for the recredit and return of an unauthorized debit to the Receiver’s
account (i.e., 60-day return with Written Statement of Unauthorized Debit).

IMPACT TO PARTICIPANTS
RDFIs: This amendment explicitly allows RDFIs to return debits related to Incomplete Transactions as
they would any other unauthorized debit to a consumer’s account. Any customer service or processing
impact to the RDFI should be minimal. RDFIs may, however, bear some programming, customer service,
and training costs associated with the expanded uses of the R10 Return Reason Code.

Receivers: Consumer Receivers benefit from the ability to be re-credited for a debit when a corresponding
payment is not made by a Third-Party Sender on the Receiver’s behalf.

ODFIs: ODFIs may need to perform additional due diligence with respect to Third-Party Sender customers
to ensure that the Third-Party Senders have the capabilities to complete transactions. ODFIs may incur
costs associated with training and due diligence costs associated with the expanded use of Return Reason
Code R10.

Originators: Originators are expected to benefit from a better resolution of the interruption of their
customers’ payments. When Originators’ customers are re-credited by their RDFIs, these customers will
be in a position to make alternative payment arrangements with Originators.

Third-Party Senders: Third-Party Senders may be subject to tighter obligations imposed by their ODFIs as
a result of the Rule. Third-Party Senders may also incur programming and training costs associated with
the expanded use of Return Reason Code R10.

TECHNICAL SUMMARY
Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the
Rules that are affected by this amendment are also included below.

• A
 rticle Three, Section 3.11 (RDFI Obligation to Recredit Receiver) – Expands this section to require
an RDFI to recredit the accountholder for a debit Entry to a Receiver’s account that is part of an
Incomplete Transaction.

• Article Three, Subsection 3.11.1 (RDFI General Obligation to Recredit Consumer Accounts) - Clarifies

ORxxx 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

that the RDFI’s recredit obligation regarding a debit Entry to a Consumer Account that is part of
an Incomplete Transaction does not apply when a partial or erroneous payment was made to the
intended third-party payee;

• A
 rticle Three, Subsection 3.12.3 (Incomplete Transaction) – Adds a new subsection defining the
concept of an Incomplete Transaction as it relates to the use of the Written Statement of Unauthorized
Debit.

• A
 rticle Three, Subsection 3.12.4 (RDFI Must Accept Written Statement of Unauthorized Debit) –
Requires an RDFI to accept a Written Statement of Unauthorized Debit from a Receiver with respect
to any Incomplete Transaction to a Consumer Account.

• A
 rticle Eight, Subsection 8.46 (“Incomplete Transaction”) – Defines the term “Incomplete Transaction”
as “a payment to an intended third-party payee that was not made or completed by the Originator,
Third-Party Sender or ODFI of a corresponding debit Entry authorized by the Receiver for the
purpose of funding the payment to the third-party payee. A partial or erroneous payment to the
intended third-party payee is not an Incomplete Transaction.”

• A
 rticle Eight, Subsection 8.98 (“Written Statement of Unauthorized Debit”) – Modifies the definition
of this term to include a written notice by a Receiver to an RDFI requesting recredit for a debit that
was part of an Incomplete Transaction.

• T
 able of Return Reason Codes – Revises the descriptions of Return Reason Code R10 to accommodate
the return of a debit Entry that is a part of an Incomplete Transaction.

2 0 1 3 O P E R AT I N G R U L E S ORxxxi
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Technical Summary of 2012 Changes to the Rules

The following is a technical summary of the changes to the NACHA Operating Rules implemented during
2012. The amendments are in chronological order based on implementation date. The text changes
were officially communicated via Supplements to the Rules, but they are summarized here for reference.
Please note that since these changes are already effective, they are not marked within the text of the 2013
Rules.

EFFECTIVE DATE: JANUARY 1, 2012

Minor Impact Changes
(Approved September 8, 2011)

In general, minor impact issues include: 1) editorial changes to address corrections to grammar and
similar errors; 2) changes to correct inconsistencies between various rules; 3) clarifications of intent; 4)
minor modifications to incorporate current practices (e.g., Operator edits, return code descriptions); and
5) changes that involve minor software modifications.

Updated Definition of Participating Depository Financial Institution

Article Eight, Section 8.61 (Participating Depository Financial Institution) – removed reference to
membership in an Association

Simplification of Definitions - Entry, Originator, Receiver and Third-Party Sender

Definitions of Entry, Originator, Receiver and Third-Party Sender

Article Eight, Section 8.33 (Entry) – added references to account types

Article Eight, Section 8.59 (Originator) – removed references to account types

Article Eight, Section 8.68 (Receiver) – removed references to account types

Article Eight, Section 8.88 (Third-Party Sender) – removed references to account types

Refinement of Definition of Return Reason Code R23 – Credit Entry Returned by Receiver
Article Three, Subsection 3.8.3.2 (Timing Requirements for Credit Entries Returned by Receiver) – modified
title and text to replace “returned” with “refused” and to indicate that the time period for return begins
when the Receiver notifies the RDFI that it has refused the entry

Appendix Four, Subpart 4.2 (Table of Return Reason Codes) - updated for corresponding clarifications
to the time frame and cross reference descriptions within Return Reason Code R23.

Editing of Appendix Eight Rules Compliance Audit Requirement Language

Appendix Eight, Part 8.2 (Audit Requirements for All Participating DFIs), Item c – removed provision that
DFI addresses findings from previous audits, which lacked a direct Rules citation

Appendix Eight, Part 8.2 (Audit Requirements for All Participating DFIs), Item f - added new audit
provision regarding DFI risk management and assessment program requirements

Appendix Eight, Part 8.3 (Audit Requirements for RDFIs), Item i – removed provision regarding RDFIs
returning entries using Return Reason Code R06 – Returned per ODFI’s Request, which lacked a direct
Rules citation

ORxxxii 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Appendix Eight, Part 8.3 (Audit Requirements for RDFIs), Item j – removed provision regarding RDFI
awareness of Return Reason Code R08 – Payment Stopped, which lacked a direct Rules citation

Appendix Eight, Part 8.4 (Audit Requirements for ODFIs), Item a – updated language to reflect Rules
changes effective in June 2010 requiring ODFI origination agreements to include the right of the ODFI
to terminate the agreement, and the right of the ODFI to audit the Originator’s or Third-Party Sender’s
compliance with the agreement and the Rules

Appendix Eight, Part 8.4 (Audit Requirements for ODFIs), Item c – removed outdated language regarding
exposure limits and replaced it with modified language related to the ODFI’s obligations to assess an
Originator’s or Third-Party Sender’s ACH activity and risks; monitor its Originator’s and Third-Party
Sender’s return activity across multiple settlement dates; enforce restrictions on the types of entries that
may be originated; and enforce the exposure limit

Modifications to Notification of Change Corporate Entry Detail Records

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements), Number of Addenda Records – added
IAT Notification of Change entries to the list of Standard Entry Class Codes for which the Number of
Addenda Records is a mandatory field in the Corporate Entry Detail Record; updated the field inclusion
requirements for the Notification of Change and Refused Notification of Change Corporate Entry Detail
Records

Appendix Five, Subpart 5.4.3 (Corporate Entry Detail Record Format for Notification of Change) – revised
the field inclusion requirement and contents for the Number of Addenda Records Field from “N/A” and
“blank” to “R” (required) and “numeric”

Appendix Five, Subpart 5.4.9 (Corporate Entry Detail Record Format for Automated Refused Notification
of Change) – revised the field inclusion requirement for the Number of Addenda Records from “M”
(mandatory) to “R” (required)

Corporate Account Takeover – Voluntary Availability Exception for RDFIs

(Approved September 8, 2011)

This rule provides an option for an RDFI to take advantage of a voluntary exception from the existing
funds availability requirements prescribed within the Rules for an ACH credit when the RDFI reasonably
suspects that the ACH credit is not authorized. The amendment allows an RDFI additional time to
investigate a suspicious credit prior to making funds available to the Receiver. The additional time
increases the likelihood that unauthorized credit entries could be identified and the associated funds
could be recovered before they are withdrawn, at which point the likelihood of recovery significantly
decreases.

The following subsections were amended to allow the RDFI exemption from the funds availability
requirements within the Rules if the RDFI reasonably suspects that a credit entry is unauthorized.

Article Three, Subsection 3.3.1.1 (General Rule for Availability of Credits)

Article Three, Subsection 3.3.1.2 (Availability for Certain Credit PPD Entries)

Risk Management Issues – Excused Delay

(Approved November 2, 2011)

This amendment revised the excused delay provisions within the Rules so that an interruption or the
suspension of payment by, or unavailability of funds from, a Participating DFI or an ACH Operator is not

2 0 1 3 O P E R AT I N G R U L E S ORxxxiii
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

a condition under which a Participating DFI may claim an excused delay. In addition, the excused delay
provision of the Rules was revised so that a Participating DFI or ACH Operator can make an excused
delay claim only “to the extent” the delay was caused by the circumstances identified in Section 1.5
(Excused Delay) for which delay may be excused.

Article One, Subsection 1.5 (Excused Delay) – Eliminated excused delay by a Participating DFI for the
interruption or the suspension of payment by, or unavailability of funds from, a Participating DFI or
another ACH Operator; and clarified that excused delay is only “to the extent” caused by interruption of
communication or computer facilities.

Pain Points in the Rules - Phase Two: WEB Exposure Limit

(Approved November 2, 2011)

This amendment changed the NACHA Operating Rules (Rules) to eliminate the ODFI requirement to
establish a separate exposure limit on Originators or Third-Party Senders of WEB Entries. This issue was
identified in the rule-making process as a “pain point;” the amendment eliminated a requirement that no
longer adds value to ACH Network users, and improved ACH processing efficiency.

Article Two, Subsection 2.2.2 (ODFI Risk Management) – incorporated language addressing
“implementation” and “review” of exposure limits established by the ODFI.

Article Two, Subsection 2.5.17.4(c) (Additional ODFI Warranties for WEB Entries – ODFI Exposure Limits)
– removed the ODFI warranty regarding the establishment of a specific exposure limit on an Originator’s
initiation of WEB Entries.

Appendix Eight, Parts 8.4 (c) and (d)  (Audit Requirements for ODFIs) – incorporated language addressing
“implementation” and “review” of exposure limits into part (c) and deleted the specific audit requirement
addressing exposure limits for WEB entries under part (d).

EFFECTIVE DATE: MARCH 16, 2012

IAT Modifications and Refinements
(Approved September 8, 2011)

The IAT Modifications and Refinements changes clarify and enhance the Rules where appropriate to
support more efficient processing of IAT Entries. Provisions with minimal or no impact on ACH Network
software or processing requirements were effective on March 16, 2012.

IAT Entries and the Effect of Illegality

Article One, Subsection 1.2.1 (Effect of Illegality) – expanded this subsection to clarify that a Participating
DFI must comply with all requirements of the Rules for any non-suspect transaction.

Clarification of Rules Exceptions for IAT Entries

Article Two, Subsection 2.5.8.2 (Authorization for Outbound IAT Entries) – defined specific authorization
requirements for Outbound IAT Entries.

Article Two, Subsection 2.5.8.5 (Rules Exceptions for Outbound IAT Entries) – updated the list of rules not
applicable to Outbound IAT Entries and clarified that certain ACH functions apply only to the extent that
they are permitted by the laws and payment system rules of the receiving country.

Article Two, Subsection 2.5.8.6 (Rules Exceptions for Inbound IAT Entries) – established a new subsection
to identify specific rules that do not apply to Inbound IAT Entries.

ORxxxiv 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Article Three, Subsection 3.4.3.3 (Specific Provisions for Outbound IAT Entries) – broadened this
subsection (including the section title) to (1) incorporate an explicit statement that a Participating DFI
acting as a Gateway assumes the responsibilities and warranties of an RDFI for each Outbound IAT Entry
it transmits, with the specific exception of the rights and obligations between the DFI and the foreign
receiver, and (2) update the current list of rules not applicable to Outbound IAT Entries.

Article Five, Subsection 5.1.6 (Gateway Action on Receipt of Notification of Change (NOC) Related to
Inbound IAT Entries) – required Gateways to notify their foreign contacts of any changes requested
through the NOC process to ensure proper processing of future ACH Entries.

Required Gateway Agreements and Authorizations for Outbound IAT Entries

Article Five, Subsection 5.1.1 (Gateway Must Enter Agreement with ODFI or Gateway’s Customer) –
broadened the Gateway agreement requirements to permit parties other than the ODFI to have an
agreement with the Gateway for the transmission of Outbound IAT Entries.

Article Five, Subsection 5.1.4 (Gateway Must Obtain Authorization from ODFI or Gateway’s Customer) –
broadened the Gateway authorization requirements to permit parties other than the ODFI to authorize
the Gateway to transmit Outbound IAT Entries to and settle with a Foreign Gateway for further credit to
the foreign receiver’s account.

Appendix Four (Return Entries), Part 4.2 (Table of Return Codes) – revised the description and cross-
reference sections of Return Reason Code R81 to broaden the discussion regarding the lack of necessary
agreements.

Return of Outbound IAT Entry by Foreign Gateway – Transmission of ACH Return by Gateway to ODFI
Article Five, Subsection 5.1.5 (Gateway Obligation to Transmit Return Entries for Outbound IAT Entries
Returned by Foreign Gateway) – added a specific obligation and time frame for a Gateway to transmit a
Return Entry related to an Outbound IAT Entry that was properly returned to it by the Foreign Gateway.

Identification of the Foreign Funding Financial Institution Within an ACH Entry

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – revised the descriptions of the following
fields within the 4th IAT Addenda Record to clarify required content:

Originating DFI Branch Country Code

Originating DFI Identification

Originating DFI Identification Number Qualifier

Originating DFI Name

Clarification of Originator Identification Field

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – revised the definition of the Originator
Identification Field within an IAT Entry to permit the inclusion of additional identifying information for
use by the ODFI.

Return Reason Codes R80-R84 – Clarification of Use For Outbound IAT Entries Only
Appendix Four, Part 4.2 (Table of Return Codes) and IAT Record Formats - R80-84 (Return Reason Codes
to be Used by Gateways for Outbound IAT Entries): clarified that these codes are for use by Gateways
only.

2 0 1 3 O P E R AT I N G R U L E S ORxxxv
R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Expansion of Return Reason Code R84 (Entry Not Processed By Gateway Operator)
Appendix Four, Part 4.2 (Table of Return Codes) and IAT Record Formats - R84 (Entry Not Processed by
Gateway): expanded the use of this return code to allow a Gateway to return an IAT Entry when the
foreign payment system does not support the function(s) needed to process the transaction.

Pain Points in the Rules - Phase Two: Expansion of ARC

(Approved November 2, 2011)

This amendment changed the NACHA Operating Rules (Rules) to permit the use of ARC for the conversion
of checks tendered via a delivery service or in person for the payment of a bill at a manned location.

Each section of the Rules listed below was revised to incorporate language permitting a check presented
(1) via a delivery service, or (2) in person for the payment of a bill at a manned location, to be converted
to an ARC entry:

Article Two, Subsection 2.5.1.1  (General Rule for ARC Entries).

Article Two, Subsection 2.5.1.2 (Authorization of ARC Entries by Notification).

Article Two, Subsection 2.5.1.3  (Eligible Source Document Required).

Article Eight, Section 8.1  (“Accounts Receivable Entry” or “ARC Entry” or “ARC”).

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements), “Standard Entry Class

Code”.

EFFECTIVE DATE: SEPTEMBER 21, 2012

IAT Modifications and Refinements
(Approved September 8, 2011)

The IAT Modifications and Refinements changes clarified and enhanced the Rules where appropriate
to support more efficient processing of IAT Entries. Provisions with a more substantial impact on ACH
software or processing requirements were effective on September 21, 2012.

Minimum Description Standards for IAT Entries

Article Three, Subsections 3.1.5.1 (RDFI Must Provide Entry Information for Consumer Accounts) and
3.1.5.2 (RDFI Must Provide Entry Information to Receivers of ARC, BOC, or POP Entries to Non-Consumer
Accounts) – revised these subsections to provide RDFIs with greater clarity regarding the information
from an IAT Entry that must be included on the Receiver’s statement.

Gateway Notification of Rejected Inbound International Payment

Article Five, Subsection 5.1.3 (Gateway Must Notify Intended RDFI of Unlawful Inbound Payment
Transaction) – established a requirement for the Gateway to notify the intended RDFI if an inbound
international payment transaction was rejected or blocked because it would violate U.S. law and provide
minimum information related to the transaction, unless prohibited by law.

Transaction Type Code to Identify Remittances

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – expanded the list of eligible code values that
may be included within the Transaction Type Code field.

ORxxxvi 2 0 1 3 O P E R AT I N G R U L E S
 R E V I S I O N S T O T H E N A C H A O P E R AT I N G R U L E S A N D G U I D E L I N E S

Dishonor of Return Entries

(Approved April 2, 2012)

The Dishonor of Return Entries change amended the Rules to eliminate a “pain point” in the Rules that
required the ODFI or Originator to have suffered a loss before being able to dishonor an untimely return.
This change eliminated a requirement that no longer added value to ACH Network users and therefore
improved ACH processing efficiency.

Article Two, Subsection 2.12.5.1  (Dishonor of Return by ODFI) - removed language in item (a) requiring
either the ODFI or Originator to substantiate a loss was suffered in order to dishonor the untimely return
entry.

2 0 1 3 O P E R AT I N G R U L E S ORxxxvii
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Supplement #2-2012 to the

NACHA Operating Rules
On October 31, 2012, NACHA’s Voting Membership approved two amendments to the NACHA Operating
Rules (Rules): ACH Security Framework and Healthcare Payments via ACH. These amendments will
become effective September 20, 2013.

This supplement provides ACH Network participants with a summary of the key components of each
change, along with details regarding the technical changes to the 2013 Rules language. Because these
amendments were approved just prior to publication of the 2013 edition of the NACHA Operating Rules
& Guidelines, the material contained in this Supplement is not included within the main body of the
publication. To ensure compliance with the most current rules, this Supplement should be used in
conjunction with the 2013 Rules.

2 0 1 3 O P E R AT I N G R U L E S ORxxxix
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

ACH Security Framework

(Approved October 31, 2012 – Effective September 20, 2013)

SUMMARY
The ACH Security Framework amendment creates a framework within the NACHA Operating Rules (Rules)
aimed at protecting the security and integrity of certain ACH data throughout its lifecycle. The Security
Framework establishes minimum data security obligations for ACH Network participants to protect ACH
data within their purview. Specifically, the Framework:

• requires non-consumer Originators, Participating DFIs, Third-Party Service Providers and Third-Party
Senders to establish, implement and, as appropriate, update security policies, procedures, and systems
related to the initiation, processing and storage of Entries and resulting Protected Information;

• requires each Participating DFI, Third-Party Service Provider, and Third-Party Sender to verify, as part
of its annual ACH Rules Compliance Audit, that it has established, implemented, and updated the data
security policies, procedures, and systems required by the Rules; and

• requires an ODFI to use a commercially reasonable method to establish the identity of each non-
consumer Originator or Third-Party Sender with which the ODFI enters into an Origination Agreement.

Background
Currently, the NACHA Operating Rules contain a number of data security and authentication requirements
for ACH transactions that are generally based on individual Standard Entry Class (SEC) Codes and/or
triggering events. The marketplace has changed since these security requirements were included in the
Rules many years ago. Sound industry practices now reflect the understanding that certain financial data
should be protected at all times - whether before, during or after transmission, and regardless of the form
of transmission (e.g., by Internet or otherwise). By establishing minimum data security obligations, the
ACH Security Framework changes will benefit the ACH Network by reducing the potential for both out-
of-pocket losses experienced by ACH participants and their customers, and the damaging effect of data
breaches on the reputation of the ACH Network and its participants.

KEY COMPONENTS OF RULE AMENDMENT

The ACH Security Framework amendment consists of three elements: (1) Protection of Sensitive Data and
Access Controls; (2) Self-Assessment; and (3) Verification of Third-Party Senders and Originators.

Protection of Sensitive Data and Access Controls

The Security Framework requires all non-consumer Originators, Participating DFIs (as both ODFIs
and RDFIs), Third-Party Service Providers, and Third-Party Senders to comply with specific security
requirements with respect to the handling and storage of Protected Information. The security requirements
will not apply directly to consumers, who can be Originators of CIE entries; however, such security
requirements will apply to parties originating CIE Entries on behalf of consumers (i.e., the consumer’s
financial institution or a Third-Party Sender).

Under this rule, non-consumer Originators, Participating DFIs, Third Party Service Providers, and Third-
Party Senders will be required to establish, implement, and, as appropriate, update security policies,
procedures, and systems related to the initiation, processing, and storage of entries. These policies,
procedures, and systems must:

ORxl 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

(1) protect the confidentiality and integrity of Protected Information;

(2) protect against anticipated threats or hazards to the security or integrity of Protected
Information; and

(3) protect against unauthorized use of Protected Information that could result in substantial
harm to a natural person.

The amendment defines Protected Information as:

the non-public personal information, including financial information, of a natural person used
to create, or contained within, an Entry and any related Addenda Record.

The definition of Protected Information not only covers financial information, but also includes sensitive
non-financial information (such as non-financial account information contained in Addenda Records for
bill payments) that may be incorporated into the Entry or any related Addenda Record.

By covering natural persons, the rule on the protection of sensitive data applies to consumer information
only, which is consistent with the approach of aligning the Security Framework with existing industry
regulations and guidance. Impacted ACH participants, however, may apply the rule more broadly so that
it covers all customers.

The security policies, procedures, and systems of ACH participants covered by the Security Framework
must include controls on system access that comply with applicable regulatory guidelines. The impacted
systems include all of those used by the ACH participant to initiate, process, and store entries. Although
it is expected that security policies will be reviewed and approved at a level of responsibility within
an organization that is commensurate with the importance of the subject matter, this amendment does
not include specific requirements regarding the level of approval of such policies and procedures, thus
providing institutions flexibility to accommodate their respective corporate governance structures.

Self-Assessment
The amendment requires each Participating DFI, Third-Party Service Provider, and Third-Party Sender
to verify, as part of the requirements for an annual ACH Rules Compliance Audit, that it has established,
implemented, and updated the data security policies, procedures, and systems required by the ACH
Security Framework.

As with all provisions of the Rules, the annual Rules Compliance Audit applies directly to DFIs and third-
parties, but not directly to Originators. Originators are bound to the NACHA Operating Rules through
their Origination Agreements with their ODFIs. As such, Originators must ensure that they have existing
policies, procedures, and systems in place that will enable compliance with the Security Framework

Verification of Third-Party Senders and Originators

The amendment establishes a requirement that an ODFI use a commercially reasonable method to
determine the identity of each non-consumer Originator or Third-Party Sender with which the ODFI
enters into an Origination Agreement, at the time the agreement is created. The NACHA Operating Rules
currently require an ODFI to warrant that the ODFI has used a commercially reasonable method to establish
the identity of the Originator or Third-Party Sender that entered into an Origination Agreement via an
Unsecured Electronic Network. The Security Framework replaces this warranty with a new prerequisite
to origination that more broadly requires the ODFI to verify the identity of all Originators/Third-Party
Senders, regardless of the manner in which the Origination Agreement was executed. The amendment
makes the requirement an obligation rather than a “warranty” as previously used for transmissions over
Unsecured Electronic Networks.

2 0 1 3 O P E R AT I N G R U L E S ORxli
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

IMPACT TO PARTICIPANTS
Originators: Each non-consumer Originator will incur costs related to an initial effort to determine
whether it has existing policies, procedures, and systems in place that would enable it to comply with
the Security Framework. A non-consumer Originator that is in compliance with existing data security
regulations should also be in compliance with the amendment and will have no to low implementation
costs. Non-consumer Originators that do not have such policies, procedures, and systems will incur costs
in establishing and/or updating such policies, procedures, and systems to ensure compliance with the
Security Framework.

ODFIs: Each ODFI will incur costs related to an initial effort to determine whether it has existing policies,
procedures, and systems in place that would enable it to comply with the amendment. An ODFI that is
in compliance with existing data security regulations should also be in compliance with the amendment
and will have no to low implementation costs. An ODFI that does not have such policies, procedures, and
systems will incur costs in establishing and/or updating such policies, procedures, and systems to ensure
compliance with the Security Framework. Each ODFI also will incur ongoing costs to make commercially
reasonable efforts to verify the identity of its Originators and Third-Party Senders. However, such costs
will only be incremental over the ODFI’s existing costs to the extent that it does not currently conduct
such assessments and verification. Finally, ODFIs would incur minimal incremental costs to add a
verification item to their annual Rules Compliance Audit.

Third-Party Service Providers and Third-Party Senders: Each Third-Party Service Provider and each Third-
Party Sender will incur costs related to an initial effort to determine whether it has existing policies,
procedures, and systems in place that will enable it to comply with the amendment. A Third-Party Service
Provider or Third-Party Sender that is in compliance with existing data security regulations should also
be in compliance with the Security Framework and will have no to low implementation costs. Each
Third-Party Service Provider or Third-Party Sender that does not have such policies, procedures, and
systems will incur costs in establishing and/or updating such policies, procedures, and systems to ensure
compliance with the Security Framework. Third-parties will incur minimal incremental costs to add a
verification item to their annual Rules Compliance Audit.

RDFIs: Each RDFI will incur initial costs to determine whether it has existing policies, procedures,
and systems in place that will allow it to comply with the amendment, to the extent the RDFI receives
Protected Information. An RDFI that is in compliance with existing data security regulations should also
be in compliance with the Rule and will have no to low implementation costs. An RDFI that does not
have such policies, procedures, and systems will incur costs in establishing and/or updating such policies,
procedures, and systems to ensure compliance with the Security Framework. Finally, RDFIs will incur
minimal incremental costs to add a verification item to their annual Rules Compliance Audit.

TECHNICAL SUMMARY
The changes to the Rules language, as noted below, represents modifications to the NACHA Operating
Rules that will become effective on September 20, 2013.

• Article One, Subsection 1.2.2  (Audits of Rules Compliance) - modified to correct language related to
Third-Party Senders for consistency throughout the Rules.

• Article One, Subsection 1.6 (Security Requirements) - new subsection incorporates general ACH
Security Requirements into the NACHA Operating Rules.

• Article Two, Subsection 2.2.1  (ODFI Verification of Originator or Third-Party Sender Identity) - new
subsection creates an obligation for the ODFI to use a commercially reasonable method to establish
the identity of each Originator or Third-Party Sender.

ORxlii 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

• Article Two, Subsection 2.4.1.8  (ODFI has Verified the Identity of Originator or Third-Party Sender
That Uses an Unsecured Electronic Network Dishonor of Return by ODFI) - this subsection is removed
from the Rules.

• Article Eight, Section 8.67  (Protected Information) - adds a definition for the new term “Protected
Information.”

• Appendix Eight, Part 8.2 (Audit Requirements for All Participating DFIs) - adds a new item “f”
that requires annual ACH Rules Compliance Audits to include a verification that the covered ACH
participants (i.e., Participating DFIs, Third-Party Service Providers, and Third-Party Senders) have
established, implemented, and updated (as appropriate) the security policies, procedures, and systems
as required by the Security Requirements provisions.

• Appendix Eight, Part 8.4  (Audit Requirements for ODFIs) - modifies item “i” for consistency with the
new subsection 2.2.1.

Implementation Date:  September 20, 2013

•  •  •  •

As approved October 31, 2012, effective September 20, 2013, the Rules are modified as follows for the rule
change related to the ACH Security Framework:

ARTICLE ONE

General Rules

SUBSECTION 1.2.2  Audits of Rules Compliance

A Participating DFI must annually conduct, or have conducted, an audit of its compliance with these
Rules in accordance with Appendix Eight (Rule Compliance Audit Requirements). A Third-Party Service
Provider, including a Third Party Sender, that has agreed with a Participating DFI to process Entries must
annually conduct, or have conducted, an audit of its compliance with these Rules in accordance with
Appendix Eight (Rule Compliance Audit Requirements).

uA Participating DFI must annually conduct, or have conducted, an audit of its compliance with these
Rules in accordance with Appendix Eight (Rule Compliance Audit Requirements). A Third-Party Service
Provider or a Third Party Sender that has agreed with a Participating DFI to process Entries must annually
conduct, or have conducted, an audit of its compliance with these Rules in accordance with Appendix
Eight (Rule Compliance Audit Requirements).

uSECTION 1.6 Security Requirements (new section)

Each non-consumer Originator, Participating DFI, and Third-Party Service Provider must establish,
implement, and update, as appropriate, policies, procedures, and systems with respect to the initiation,
processing, and storage of Entries that are designed to:

(a)  protect the confidentiality and integrity of Protected Information until its destruction;

(b) protect against anticipated threats or hazards to the security or integrity of Protected

Information until its destruction; and

2 0 1 3 O P E R AT I N G R U L E S ORxliii
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

(c) protect against unauthorized use of Protected Information that could result in substantial
harm to a natural person.

Such policies, procedures, and systems must include controls that comply with applicable regulatory
guidelines on access to all systems used by such non-consumer Originator, Participating DFI, or Third-
Party Service Provider to initiate, process, and store Entries.

An ODFI may dishonor a Return Entry, with the exception of an IAT Return Entry, if:

ARTICLE TWO

Rights and Responsibilities of ODFIs, Their Originators and Third-Party

Senders

uSUBSECTION 2.2.1 ODFI Verification of Originator or Third-Party Sender Identity (new subsection)

The ODFI must utilize a commercially reasonable method to verify the identity of an Originator or Third-
Party Sender at the time the ODFI enters into an Origination Agreement with the Originator or Third-
Party Sender.

SUBSECTION 2.4.1.8  The ODFI has Verified the Identity of Originator or Third-Party Sender That Uses an
uUnsecured Electronic Network (this subsection will be removed from the Rules)

The ODFI has utilized a commercially reasonable method to establish the identity of an Originator or
Third-Party Sender that entered into an Origination Agreement via an Unsecured Electronic Network.

ARTICLE EIGHT

Definitions of Terms Used in These Rules

uSECTION 8.67  “Protected Information”

the non-public personal information, including financial information, of a natural person used to create,
or contained within, an Entry and any related Addenda Record.

APPENDIX EIGHT

Rule Compliance Audit Requirements

PART 8.2  Audit Requirements for All Participating DFIs

Each Participating DFI, Third-Party Service Provider, and Third-Party Sender must conduct the following
audit of ACH operations. These audit specifications apply generally to all Participating DFIs, regardless
of a Participating DFI’s status as an ODFI or RDFI.

a. Verify that a Record of each Entry is retained for six years from the date the Entry was Transmitted,
except as otherwise expressly provided in these Rules. Verify that a printout or reproduction of
the information relating to the Entry can be provided, if requested by the Participating DFI’s

ORxliv 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

customer or any other Participating DFI or ACH Operator that originated, Transmitted, or received
the Entry. (Article One, subsections 1.4.1 and 1.4.2)

b. When a Record required by these Rules is created or retained in an Electronic form, verify that
the Electronic form (a) accurately reflects the information in the Record, and (b) is capable of
being accurately reproduced for later reference, whether by Transmission, printing, or otherwise.
(Article One, subsection 1.4.3)

c. Verify that the Participating DFI conducted an audit of its compliance with the rules in accordance
with Appendix Eight (Rule Compliance Audit Requirements) for the previous year. (Article One,
subsection 1.2.2)

d. Verify that required encryption or a secure session is used for banking information transmitted via
an Unsecured Electronic Network. (Article One, subsection 1.6)

e. Verify that the Participating DFI has reported and paid to the National Association (a) all annual
fees, and (b) a per-Entry fee for each Entry that is Transmitted or received by the Participating DFI,
including those Entries that are not processed through an ACH Operator but are exchanged with
another non-affiliated Participating DFI. (Article One, subsection 1.10)

f. Verify that the Participating DFI has conducted an assessment of the risks of its ACH activities and
has implemented a risk management program on the basis of such an assessment. (Article One,
subsection 1.2.4)

u g. 
Verify that the Participating DFI has established, implemented and updated, as appropriate,
security policies, procedures and systems as required by Article One, Section 1.6. (Article One,
Section 1.6).

PART 8.4  Audit Requirements for ODFIs

In addition to the audit procedures outlined in Parts 8.1 (General Audit Requirements) and 8.2 (Audit
Requirements for All Participating DFIs) of this Appendix Eight, ODFIs, Third-Party Service Providers,
and Third-Party Senders must conduct an audit of the following relating to the origination of ACH entries:

a. Verify that the ODFI has entered into Origination Agreements with all Originators or Third-Party
Senders that bind the Originator or Third-Party Sender to these Rules; that authorize the ODFI to
originate entries on behalf of the Originator or Third-Party Sender; that, within such agreements,
the Originator or Third-Party Sender acknowledges that Entries may not be initiated that violate
the laws of the United States; that includes any restrictions on types of Entries that may be
originated; that includes that the Third-Party has entered into an agreement with each Originator/
and that such agreements include the right of the ODFI to terminate or suspend the agreement for
breach of the Rules, and the right of the ODFI to audit the Originator’s, the Third-Party Sender’s
and the Third-Party Sender’s Originators’ compliance with the Origination Agreement and the
Rules. With respect to IAT Entries, verify that agreements contain all necessary provisions. (Article
Two, subsections 2.2.1.1, 2.2.1.2 and 2.5.8.3)1

b. Verify that, if applicable, the ODFI has entered into agreements with all Sending Points that
Transmit Entries on the ODFI’s behalf to an ACH Operator. (Article Two, subsection 2.2.1.3)

c. Verify that the ODFI has assessed the risks of the Originator’s or Third-Party Sender’s ACH activity,
and has established and implemented an exposure limit for each Originator or Third-Party Sender.
1 
Article Two, Subsections 2.2.1.1(d), (e) and (f) and 2.2.1.2(d), (e), (f) and (g) are applicable to Origination Agreements that were entered into on
or after June 18, 2010.

2 0 1 3 O P E R AT I N G R U L E S ORxlv
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Verify that the ODFI has established, implemented, and periodically reviewed procedures to
monitor the Originator’s or Third-Party Sender’s origination and return activity across multiple
Settlement Dates; enforce restrictions on the types of Entries that may be originated; and enforce
the exposure limit. (Article Two, subsection 2.2.2)

d. Verify that the ODFI accepts Return Entries and Extended Return Entries that comply with these
Rules and that are Transmitted by the RDFI within the time limits established by these Rules. Verify
that dishonored Return Entries are Transmitted within five banking days after the Settlement Date
of the Return Entry and that contested dishonored Return Entries are accepted, as required by
these rules. Verify that the ODFI is using return reason codes in an appropriate manner. (Article
Two, subsections 2.12.1, 2.12.5.1, and 2.12.5.2; Appendix Four)

e. Verify that information relating to NOCs and Corrected NOCs is provided to each Originator or
Third-Party Sender within two Banking Days of the Settlement Date of the NOC or Corrected
NOC in accordance with Appendix Five (Notification of Change). Verify that refused NOCs are
Transmitted within fifteen (15) days of receipt of an NOC or corrected NOC. (Article Two,
subsections 2.11.1 and 2.11.2)

f. With the exception of XCK entries, verify that the ODFI provides to the RDFI, upon receipt
of the RDFI’s written request, the original, a copy, or other accurate Record of the Receiver’s
authorization with respect to a Consumer Account within ten banking days without charge.
(Article Two, subsections 2.3.2.5 and 2.5.18.6)

g. Verify that, when agreed to by the ODFI, late Return Entries are accepted in accordance with these
rules. (Article Two, subsection 2.12.6)

h. Verify that the ODFI has provided the Originator with proper notice to ensure compliance with
UCC Article 4A with respect to ACH transactions. (Article Two, subsection 2.3.3.2)

i. Verify that the ODFI has utilized a commercially reasonable method to establish the identity
of each Originator or Third-Party Sender that uses an Unsecured Electronic Network to enter
into an Origination Agreement with the ODFI. When an ODFI has a relationship with a Third-
Party Sender rather than with an Originator directly, also verify that the Third-Party Sender has
utilized a commercially reasonable method to establish the identity of each Originator that uses
an Unsecured Electronic Network to enter into an Origination Agreement with the Third-Party
Sender. (Article Two, subsections 2.4.1.8 and 2.15.2)

u i. Verify that the ODFI has utilized a commercially reasonable method to verify the identity of each
Originator or Third-Party Sender that enters into an Origination Agreement with the ODFI. When
an ODFI has a relationship with a Third-Party Sender rather than with an Originator directly,
also verify that the Third-Party Sender has utilized a commercially reasonable method to establish
the identity of each Originator that enters into an Origination Agreement with the Third-Party
Sender. (Article Two, subsection 2.2.1)

j. Verify that Reversing Entries and Reversing Files are initiated in accordance with the requirements
of these Rules. (Article Two, sections 2.8 and 2.9)

k. 
For BOC Entries, verify that the ODFI has (1) established and implemented commercially
reasonable procedures to verify the identity of each Originator or Third-Party Sender of such
entries; and (2) established and implemented procedures to document specific information with
respect to each Originator, as required by these rules, and that, upon request, such information is
provided to the RDFI within the required time frame. (Article Two, subsection 2.5.2.5)

ORxlvi 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

l. Verify that the ODFI has reported Return Rate information on each Originator or Third-Party
Sender, as requested by the National Association. (Article Two, subsection 2.17.2)

m. Verify that the ODFI has (1) registered its Direct Access status with the National Association; (2)
obtained the approval of its board of directors, committee of the board of directors, or its designee
for each Direct Access Debit Participant; (3) provided required statistical reporting for each Direct
Access Debit Participant; and (4) notified the National Association of any change to the information
previously provided with respect to any Direct Access Debit Participant. (Article Two, subsection
2.17.1)

n. Verify that the ODFI has kept Originators and Third-Party Senders informed of their responsibilities
under these rules. (Article Two, section 2.1)

2 0 1 3 O P E R AT I N G R U L E S ORxlvii
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Healthcare Payments via ACH

(Approved October 31, 2012 – Effective September 20, 2013)

SUMMARY
The Healthcare Payments via ACH changes amend the NACHA Operating Rules (“Rules”) to support health
plans’ and healthcare providers’ use of the ACH Network for healthcare claims payments and payment
related information. This amendment includes processing enhancements and transaction identification
and formatting requirements specific to healthcare claim payments.

Background
The Patient Protection and Affordable Care Act (ACA) requires the Department of Health and Human
Services (HHS) to adopt a standard for Health Care Electronic Funds Transactions, as well as industry-
vetted operating rules regarding the use of the standard transaction. On January 10, 2012, HHS issued
an Interim Final Rule with Comment2 that:

1) adopted the NACHA Corporate Credit or Debit Entry with Addenda Record (CCD+) as the
standard for Healthcare EFT (electronic funds transfers);

2) adopted the ASC X12 835 TRN Segment (“reassociation number”)3 as the standard for the
data content of the Addenda Record of the CCD+; and

3) discussed NACHA’s role in the development and maintenance of the CCD+ standard through
the Rules.

On August 10, 2012, HHS issued another Interim Final Rule with Comment4 that adopted the Council on
Affordable Quality Healthcare Committee on Operating Rules for Information Exchange (CORE) Phase III
CORE EFT & ERA Operating Rule Set as the industry-vetted operating rules for EFT and ERA (electronic
remittance advice). The CORE rule set includes five Operating Rules, of which the most critical for
financial institutions is the Phase III CORE EFT & ERA Reassociation (CCD+/835) Rule. The EFT & ERA
Reassociation Rule

• requires that the “provider must proactively contact its financial institution to arrange for the
delivery of the CORE-required Minimum CCD+ Data Elements” and obligates health plans
to proactively inform health care providers of this requirement during EFT enrollment; and

• describes the CORE-required Minimum CCD+ Data Elements as three fields in the ACH
CCD record that are used for reassociation of the ACH Entry and the Electronic Remittance
Advice (ERA): 1) the Effective Entry Date field (CCD Record 5, Field 9); 2) the Amount
field (CCD Record 6, Field 6); and 3) the Payment Related Information field (CCD Record
7, Field 3).

2
Administrative Simplification: Adoption of Standards for Health Care Electronic Funds Transfers (EFTs) and Remittance Advice, http://www.gpo.gov/
fdsys/pkg/FR-2012-01-10/pdf/2012-132.pdf
3
The reassociation number does not constitute Protected Health Information as defined by HIPAA.
4
Administrative Simplification: Adoption of Operating Rules for Health Care Electronic Funds Transfers (EFT) and Remittance Advice Transactions,
http://www.gpo.gov/fdsys/pkg/FR-2012-08-10/pdf/2012-19557.pdf

ORxlviii 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

KEY COMPONENTS OF RULE AMENDMENT

The Healthcare Payments via ACH amendment consists of five components.

Unique Identification of Health Care EFTs

This amendment requires Originators to clearly identify CCD Entries that are Health Care EFT Transactions
through the use of a specific identifier. The presence or absence of this healthcare-specific indicator
provides RDFIs with certainty in distinguishing Health Care EFT Transactions from non-health care CCD
Entries, allowing RDFIs the ability to comply with the Rules and specific processing requests from health
care customers.

Specifically, the new rules require Originators of Health Care EFT Transactions to populate the Company
Entry Description field of the CCD Entry with the value “HCCLAIMPMT”. RDFIs will be able to identify
a CCD Entry with this standard description as a Health Care EFT Transaction. This descriptive statement
is readable, providing healthcare providers with additional information about the payment. Finally, this
standard description enables various ACH participants (including NACHA in cooperation with the ACH
Operators) to have greater data available on the volume of Health Care EFT Transactions.

Additional Formatting Requirements for Health Care EFT Transactions

For each CCD Entry that contains the healthcare indicator, as described above, the Originator is required
to ensure that the CCD Entry complies with the following formatting requirements, which are necessary
to provide Receivers (healthcare providers) with clear identification of the source and purpose of the
payment.

• Company Name

As is required for all ACH transactions, the Company Name field must be populated with information
that is readily recognized by the Receiver, in this case a healthcare provider. The amendment requires an
Originator of a Health Care EFT Transaction to populate the Company Name field of the CCD Entry with
the name of the health plan. In situations where an organization is self-insured, this field could contain
the name of the organization’s third-party administrator that is recognized by the healthcare provider
and to which the healthcare provider submits its claims. Recognizing that there are other potential
variations in health claims processing models, the overarching intent of NACHA’s existing Company Name
Rule applies – that the Company Name field contain the name of the payor that is known and readily
recognized by the Receiver (healthcare provider).

• Addenda Record and Payment Related Information Requirements for Health Care EFT Transactions

The new rule requires Originators to include an addenda record with each CCD Entry used for a Health
Care EFT Transaction. The rule also requires Originators to populate the Payment Related Information
field of the addenda record with the ANSI ASC X12 Version 5010 835 TRN (Reassociation Trace Number)
data segment. The TRN data segment, along with additional information contained within the Entry,
is needed by healthcare providers to reassociate the Health Care EFT Transaction with the electronic
remittance advice (ERA) that is transmitted separately.

Delivery of Payment Related Information (Reassociation Number)

The Healthcare Payments via ACH amendment aligns with the existing rules regarding the delivery of
payment related information.5 The rule requires an RDFI to provide or make available, either automatically
5
Among ACH participants, the Payment Related Information is commonly referred to as the “remittance information.” For a CCD Entry that is a
Health Care EFT, the Payment Related Information will always contain the “reassociation number” (i.e., the ASC X12 835 TRN Segment), and not
detailed remittance information that contains Protected Health Information. Readers should not confuse the common ACH usage of “remittance
information” with the terms “remittance advice” or “electronic remittance advice (ERA)” as used in the health care industry to mean the detailed
explanation of benefits.

2 0 1 3 O P E R AT I N G R U L E S ORxlix
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

(if such a service is established by the RDFI) or upon the request of a Receiver that is a healthcare
provider, all information contained within the Payment Related Information field of an Addenda Record
transmitted with a CCD Entry that is a Health Care EFT Transaction. The RDFI is required to provide
or make available the Payment Related Information no later than the opening of business on the RDFI’s
second Banking Day following the Settlement Date of the Entry. The rule also requires the RDFI to offer or
make available to the healthcare provider an option to receive or access the Payment Related Information
via a secure, electronic means that provides a level of security that, at a minimum, is equivalent to 128-bit
RC4 encryption technology.

Under this rule, an RDFI’s obligation to provide healthcare EFT payment related information upon the
Receiver’s request is very similar to current requirements for other business-to-business payments. The
rule, however, explicitly incorporates language regarding the “automatic” provision or delivery of payment
related information transmitted with a Health Care EFT Transaction as an option for RDFIs. Any RDFI
that decides to automatically provide this information to Health Care Provider customers, without waiting
for it to be requested, would be in compliance with the rule. The inclusion of the term “automatically”
as an option does not require the RDFI to proactively deliver the information, but recognizes that there
are RDFIs that, either now or in the future, automatically provide the payment related information to
their customers through online access to their account information or other methods. While automatic
delivery of payment related information has always been acceptable for CCD Entries, the addition of
the term “automatically” at this time recognizes this capability, especially as relates to health care, and
acknowledges that the automatic delivery of the data is in compliance with the new rule.

The requirement that an RDFI must offer, or make available, to Health Care Providers an option to
receive the healthcare payment related information electronically via a secure electronic delivery channel
adopts an encryption standard that is consistent with other data security requirements under the NACHA
Operating Rules (see Article One, Section 1.6) regarding the secure transmission of banking information
over unsecured electronic networks. It is consistent with CAQH CORE rules regarding “connectivity” via
the public Internet using SSL/HTTPS-level security. Examples of a secure, electronic delivery channel can
include SSL or HTTPS secure e-mail, online account access, online reports, or file transmissions that meet
the 128-bit RC4 encryption technology minimum standard. Mail, unsecured fax or unsecured e-mail of
payment related information is not considered a secure, electronic delivery method.

Finally, the rule clarifies that the new reassociation information delivery requirements apply to Health
Care EFT Transactions that are sent to Non-Consumer Accounts of Receivers. While the existing rules
have always been based on the presumption that SEC Codes are used correctly (in this case, that CCDs
are business-to-business transactions and directed to business accounts), the rule clarifies that RDFIs will
not incur new obligations if Receivers do not use appropriately designated Non-Consumer Accounts to
receive Health Care EFT Transactions.

Addition of New EDI Data Segment Terminator

The Healthcare Payments via ACH changes provide for the use of a second data segment terminator, the
tilde (“~”), to any data segments carried in the Addenda Record of the CCD Entry.6 As the tilde is a valid
character for ACH Entries, it should already be recognized as such by ACH processing software. EDI
translation software, however, might need to be modified to recognize the tilde as a valid data segment
terminator for the CCD Addenda Record and NACHA-approved banking conventions.

6
Appendix Three of the NACHA Operating Rules currently defines the asterisk (“*”) as the delimiter between data segments, and the backslash (“\”) as
the terminator indicating the end of a data segment included within the addenda records of ACK, ATX, CCD, CIE, ENR, IAT, PPD, and WEB Entries.
The proposed addition of the tilde as a valid data segment terminator for health care CCD Entries would also apply to all of these SEC Codes to
ensure consistent processing of remittance information.

ORl 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Healthcare Terminology within the NACHA Operating Rules

This rule expands the defined terms within the NACHA Operating Rules to 1) incorporate four health
care-specific concepts within their scope, and 2) define a Non-Consumer Account to ensure appropriate
application of health care-specific rules by ACH participants.

Health Care EFT Transaction:  a CCD Entry originated by a Health Plan to a Health Care Provider with
respect to a health care claim. Under this definition, a Health Care EFT Transaction must include one
addenda record that contains an ASC X12 Version 5010 835 TRN (Reassociation Trace Number) data
segment within the Payment Related Information field.

Health Plan:  an individual or group plan that provides, or pays the cost of, medical care.

Health Care Provider:  a provider of medical or health services, and any other person or organization
who furnishes, bills, or is paid for health care in the normal course of business.

CORE-required Minimum CCD+ Reassociation Data Elements:  information transmitted by a Health Plan
to a Health Care Provider for the purpose of re-associating a Health Care EFT Transaction with an
electronic remittance advice. The CORE-required Minimum CCD+ Reassociation Data Elements include
the information contained within the Effective Entry Date field, the Amount field, and the Payment
Related Information field of the CCD Entry.

In addition, this adds a definition for Non-Consumer Account to assist ACH Participants in properly
applying rules governing Health Care EFT Transactions. The term Non-Consumer Account is used to
clarify the types of accounts for which the requirements to provide or make available payment related
information apply.

Non-Consumer Account:  an account held by a Participating DFI and established by an Organization

primarily for commercial purposes. A Non-Consumer Account may be established by a natural person if
the Participating DFI’s records indicate that the account is primarily for commercial and not for personal,
family, or household purposes (i.e., it is not a Consumer Account).

IMPACT TO PARTICIPANTS
Receivers: Receivers (Health Care Providers) should not incur any direct costs as a result of the adoption
of these changes. Existing bank accounts can readily accept the receipt of ACH credit payments. Health
Care Providers that elect to upgrade systems to automatically use the TRN Reassociation Data Segment
to reassociate the ACH payment with the electronic remittance advice transmitted separately may incur
some transition costs.

RDFIs: RDFIs that do not currently offer a secure, electronic means of delivering payment related
information to their business customers will need to establish a means of doing so and make such access
available to Health Care Providers receiving Health Care EFT Transactions. RDFIs with EDI translation
software also may incur programming costs to ensure that the tilde is recognized as a valid data segment
terminator for ACH entries.

ODFIs and Originators of Health Care EFT Transactions: These participants may incur one-time
programming costs if they choose to automate the formatting of Health Care EFT Transactions to include
the required Company Entry Description and the required addenda record.

2 0 1 3 O P E R AT I N G R U L E S ORli
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

TECHNICAL SUMMARY
Below is a summary of the impact of this rule change on the NACHA Operating Rules. Sections of the
Rules that are affected by this amendment are also included below and reflect rule language as it will
read upon implementation.

• Article Two, Subsection 2.5.3 (General Rule for CCD Entries – Corporate Credit or Debit Entry) -
identifies Health Care EFT Transactions as CCD Entries having a mandatory addenda record in which
required health care payment related information must be included.

• Article Three, Subsection 3.1.5.3  (RDFI Must Provide Payment-Related Information to Receivers of
CCD, CTX, CIE and IAT Entries to Non-Consumer Accounts) -

– r equires RDFIs to provide or make available, either automatically or upon the request of a
Receiver that is a Health Care Provider, all information contained within the Payment Related
Information field of an Addenda Record transmitted with a Health Care EFT Transaction.

– r equires RDFIs to offer Health Care Provider Receivers a secure, electronic delivery channel
for the receipt of health care payment related information.

– a dds language recognizing that some RDFIs automatically provide their business customers
with payment related information.

• Article Eight, Subsections 8.19, 8.44, 8.45, 8.46, and 8.57 - new subsections to define the following
terms within the Rules:

–  ORE-required Minimum CCD+ Reassociation Data Elements

C
– Health Plan
– Health Care EFT Transaction
– Health Care Provider
– Non-Consumer Account

• Appendix One, Part 1.2 (Data Specifications for ACH Records) - requires the Company Entry
Description specific to Health Care EFT Transactions to be presented in upper case characters.

• Appendix Three, Subpart 3.1.8  (Sequence of Records for CCD Entries) - adds footnotes specific to
Health Care EFT Transactions to the CCD record layouts.

• Appendix Three, Subpart 3.2.2  (Glossary of Data Elements) - expands the descriptions of the following
fields to accommodate formatting requirements specific to Health Care EFT Transactions:

–  ddenda Record Indicator

A
– Company Entry Description
– Company Name
– Payment Related Information

Implementation Date:  September 20, 2013

•  •  •  •

As approved October 31, 2012, effective September 20, 2013, the Rules are modified as follows for the rule
changes related to Healthcare Payments via ACH:

ORlii 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

ARTICLE TWO

Rights and Responsibilities of ODFIs, Their Originators

and Third-Party Senders

SUBSECTION 2.5.3  General Rule for CCD Entries (Corporate Credit or Debit Entry)
A CCD Entry is originated by an Organization to or from the account of that Organization or another
Organization. A CCD Entry may be a credit Entry or a debit Entry, and may provide payment related
information in one Addenda Record. A CCD Entry may also be a Non-Monetary Entry that carries
payment related information in one Addenda Record.

uA CCD Entry that is a Health Care EFT Transaction must include one Addenda Record that contains the
ASC X12 835 TRN (Reassociation Trace Number) data segment in the Payment Related Information field.

ARTICLE THREE

Rights and Responsibilities of RDFIs and Their Receivers

SUBSECTION 3.1.5.3  RDFI Must Provide Payment-Related Information to Receivers of CCD, CTX, CIE and
IAT Entries to Non-Consumer Accounts
Upon the request of a Receiver, an RDFI must provide to the Receiver all information contained within
the Payment Related Information field of an Addenda Record(s) Transmitted with a CCD or CTX Entry, or
a CIE or IAT Entry to a non-Consumer Account. The RDFI must provide this information by the opening
of business on the RDFI’s second Banking Day following the Settlement Date of the Entry.

uUpon the request of a Receiver, an RDFI must provide to the Receiver all information contained within the
Payment Related Information field of an Addenda Record(s) Transmitted with a CCD Entry that is not a
Health Care EFT Transaction, a CTX Entry, or a CIE or IAT Entry to a Non-Consumer Account. The RDFI
must provide this information by the opening of business on the RDFI’s second Banking Day following the
Settlement Date of the Entry.

For a Health Care EFT Transaction to a Non-Consumer Account, an RDFI must, either automatically or
upon the request of a Receiver that is a Health Care Provider, provide or make available all information
contained within the Payment Related Information field of the Addenda Record Transmitted with the
Health Care EFT Transaction. The RDFI must provide or make available the Payment Related Information
by the opening of business on the RDFI’s second Banking Day following the Settlement Date of the Entry.
The RDFI must offer or make available to the Health Care Provider an option to receive or access the
Payment Related Information via a secure, electronic means that provides a level of security that, at a
minimum, is equivalent to 128-bit RC4 encryption technology.

2 0 1 3 O P E R AT I N G R U L E S ORliii
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

ARTICLE EIGHT

Definitions of Terms Used in These Rules

u SECTION 8.19 “CORE-required Minimum CCD+ Reassociation Data Elements”

(new section)
information transmitted by a Health Plan to a Health Care Provider in a Health Care EFT Transaction
for the purpose of reassociating the Health Care EFT Transaction with an electronic remittance advice.
The CORE-required Minimum CCD+ Reassociation Data Elements include the information contained
within the Effective Entry Date field, the Amount field, and the Payment Related Information field of the
CCD Entry.

uSECTION 8.44 “Health Plan” (new section)

an individual or group plan (including a self-insurance plan) that provides, or pays the cost of, medical
care (i.e., the meaning of “Health Plan” assigned at 45 CFR 160.103, as modified from time to time).

uSECTION 8.45 “Health Care EFT Transaction” (new section)

a CCD Entry originated by a Health Plan to a Health Care Provider with respect to a health care claim.
A Health Care EFT Transaction must be accompanied by one Addenda Record that contains the ASC X12
835 TRN (Reassociation Trace Number) data segment in the Payment Related Information field.

u SECTION 8.46 “Health Care Provider” (new section)

a provider of medical or health services, and any other person or organization who furnishes, bills, or
is paid for health care in the normal course of business (i.e., the meaning of “Health Care Provider”
assigned at 45 CFR 160.103, including a provider of certain services specified in the regulation, as
modified from time to time).

u SECTION 8.57 “Non-Consumer Account” (new section)

an account held by a Participating DFI and established by an Organization primarily for commercial
purposes. A Non-Consumer Account may be established by a natural person if the Participating DFI’s
records indicate that the account is primarily for commercial and not for personal, family, or household
purposes (i.e., it is not a Consumer Account).

APPENDIX ONE

ACH File Exchange Specifications

PART 1.2  Data Specifications for

ACH Records
The following table shows the data specifications for ACH Records.

ORliv 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

TYPE OF ALPHABETIC/
NUMERIC
FIELD ALPHAMERIC
0-9, A-Z, a-z, space,
EBCDIC values greater
Valid
than hexadecimal “3F”, 0-9
Characters
ASCII values greater than
hexadecimal “1F”

Justification Left Right

Empty Field
Space filled Zero filled
Handling

Certain fields require the use Must be unsigned

Special
of UPPER CASE characters (Neither positive (+) or
Notes
– see below. negative (–) signage.)

UPPER CASE characters must be used for all of the following:

• all alphabetic characters within the Standard Entry Class Code field;

• all alphabetic characters within the File ID Modifier field;

• all alphabetic characters within the Change Code and Refused COR Code fields;

• all alphabetic characters within the Return Reason Code, Dishonored Return Reason Code, and
Contested Dishonored Return Reason Code fields;

• Company Entry Description fields containing the words “REVERSAL,” “RETURN FEE,” “RECLAIM,”
“NONSETTLED,” “AUTOENROLL” (for ENR entries), “REDEPCHECK” (for RCK entries), and “NO
CHECK” (for XCK entries); and

u • C
 ompany Entry Description fields containing the words “REVERSAL,” “RETURN FEE,” “RECLAIM,”
“NONSETTLED,” “AUTOENROLL” (for ENR entries), “REDEPCHECK” (for RCK entries), “NO CHECK”
(for XCK entries), and “HCCLAIMPMT” (for Health Care EFT Transactions); and

• Company Name fields containing the words “CHECK DESTROYED” (for XCK entries).

APPENDIX THREE

ACH Record Format Specifications

SUBPART 3.2.2  Glossary of Data Elements

Addenda Record Indicator: 1 Position - Entry Detail Record and Corporate Entry Detail Record –
Mandatory (ACK, ADV, ARC, ATX, BOC, CCD, CIE, CTX, DNE, ENR, IAT, MTE, POP, POS, PPD, RCK, SHR,
TEL, TRC, TRX, WEB, XCK, refused ACK, refused ATX, Returns, dishonored Returns, contested dishonored
Returns, COR, refused COR)

This field indicates the existence of an Addenda Record.

2 0 1 3 O P E R AT I N G R U L E S ORlv
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Code Values:
0 No Addenda Record follows the Entry
1 One or more Addenda Records follow the Entry

u CCD: When used for a Health Care EFT Transaction, the value of this field must be “1.”

IAT: The value of this field for all IAT Entries, including IAT Prenotification Entries, will always be “1.”

Zero dollar CCD, CTX, and IAT Entries, Notification of Change, Refused Notification of Change, Return,
Dishonored Return, Contested Dishonored Return, DNE, ENR, MTE, POS, SHR, and TRX Entries: The
value of this field will always be “1”. This is not applicable to MTE, POS, SHR, or TRX Prenotifications.

Company Entry Description: 10 Positions – Company/Batch Header Record – Mandatory (all batches)

The Originator establishes the value of this field to provide the Receiver with a description of the
purpose of the Entry. For example, “Gas bill,” “Reg. Salary,” “ins. prem.,” “Soc. Sec.,” “DTC,” “Trade Pay,”
“PURCHASE,” etc.

This field must contain the word “NONSETTLED” when the batch contains Entries that could not settle.

This field must contain the word “RECLAIM” when the batch contains Reclamation Entries.

This field must contain the words “RETURN FEE” when the batch contains Return Fee Entries

This field must contain the word “REVERSAL” when the batch contains Reversing Entries.

ADV: The Originator, i.e., the Originating ACH Operator, uses this field to describe to the institution
receiving the ADV File the type of activity to which the accounting information relates.

uCCD: This field must contain the word “HCCLAIMPMT” when the batch contains Health Care EFT
Transactions.

ENR: This field must contain the word “AUTOENROLL” when the batch contains Automated Enrollment
Entries.

RCK: This field must contain the word “REDEPCHECK”.

TRX: This field contains the routing number of the keeper.

XCK: This field must contain the words “NO CHECK”.

Company Name: 16 Positions – Company/Batch Header Record – Mandatory (all batches except IAT)

This field identifies the source of the Entry and is used for descriptive purposes for the Receiver. Except
as otherwise noted below, this field must contain the name by which the Originator is known to and
readily recognized by the Receiver of the Entry.

In a transaction in which the Originator of a debit Entry is not the payee of the transaction (the party to
which payment is ultimately being directed), the Company Name field of the debit Entry must contain
the name by which the payee is known to and readily recognized by the Receiver of the Entry. In a

ORlvi 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

transaction in which the Originator of a credit Entry is not the payor of the transaction (the party from
which payment is ultimately being directed), the Company Name field of the credit Entry must contain
the name by which the payor is known to and readily recognized by the Receiver of the Entry.

For Return Fee Entries, this field must contain the same name of the Originator as identified in the
Company Name field of the underlying Entry. For a Return Fee Entry based on the return of a Check, the
Company Name field must contain the name of the payee of the Check.

ADV: The ACH Operator is both the Originator and the ODFI. The ACH Operator originating the ADV
File identifies itself by name in this field.

ARC, BOC: This field identifies the payee of the Eligible Source Document or the payee name indicated
on the bill or invoice.

u CCD: For a Health Care EFT Transaction, this field must contain the name of the Health Plan originating the
Entry, or, where an organization is self-insured, the name of the organization’s third-party administrator
that is recognized by the Health Care Provider and to which the Health Care Provider submits its claims.

CIE: This field contains the bill payment service provider’s name.

MTE: This field identifies the owner of the terminal where the transaction was initiated.

POP, POS, SHR: This field identifies the merchant with whom the Receiver initiated the transaction.

RCK: This field identifies the Originator of the RCK Entry, which is the original payee on the face of the
Check.

TRC: This field identifies the name of the keeper.

XCK: This field must contain the words “CHECK DESTROYED” (left justified).

Payment Related Information: 80 Positions – Addenda Record – Optional (ACK, ATX, CCD, CIE, CTX,
DNE, ENR, IAT, PPD, TRX, WEB)

In the Addenda Records of ACK, ATX, CCD, CIE, ENR, IAT, PPD, and WEB Entries, an asterisk (“*”)
must be used as the delimiter between the data elements, and the backslash (“\”) must be used as the
terminator between the data segments.

uIn the Addenda Records of ACK, ATX, CCD, CIE, ENR, IAT, PPD, and WEB Entries, an asterisk (“*”) must
be used as the delimiter between the data elements, and the backslash (“\”) or tilde (“~”) must be used as
the terminator at the end of a data segment.

ACK, ATX: This field contains the ANSI ASC X12 REF (Reference) data segment. This REF segment is
used to convey the Identification Number contained within the original CCD or CTX Entry, and/or other
information of significance to the Originator.

CCD, PPD, WEB: Addenda Records contain payment related ANSI ASC X12 data segments or NACHA
endorsed banking conventions (i.e., Tax Payment, Third-Party Tax Payments, Child Support, or Electronic
Dealer Drafting).

2 0 1 3 O P E R AT I N G R U L E S ORlvii
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

u CCD,PPD, WEB: Addenda Records contain payment related ANSI ASC X12 data segments or NACHA
endorsed banking conventions (i.e., Tax Payment, Third-Party Tax Payments, Child Support, or Electronic
Dealer Drafting). For CCD Entries that are Health Care EFT Transactions, this field must contain the
ASC X12 835 TRN (Reassociation Trace Number) data segment, which conveys the Reassociation Trace
Number used by the Health Care Provider to match the payment to remittance data.

Example: TRN*1*12345*1512345678*999999999\
Example: TRN*1*12345*1512345678*999999999~

CIE: This field contains payment related ANSI ASC X12 data segments to further identify the payment or
Transmit additional remittance information.

For Example:
N1*BT*JohnDoe\N3*12MainStreet\N4*21070\

CTX: This field contains information formatted in accordance with the syntax of ANSI ASC X12.5 and
X12.6, an ASC X12 transaction set containing a BPR or BPS data segment, or payment related UN/
EDIFACT syntax.

ANSI ASC X12.5 (“Interchange Control Structure”) means the standard to define the control structures
for the electronic interchange of business transactions encoded in ASC X12-based syntax. This standard
provides the interchange envelope of a header and trailer for the electronic interchange through a data
transmission, a structure to acknowledge the receipt and processing of this envelope, and optional,
interchange-level service request structures.

ANSI ASC X12.6 (“Application Control Structure”) means the standard used to define the structure of
business transactions for computer-to-computer interchange. This structure is expressed using a symbolic
representation of X12 data in terms of both the design and use of X12 structures, independent of the
physical representation (e.g., character set encoding).

BPR or BPS Data Segment (“Beginning Segment for Payment Order/Remittance Advice”) means the
beginning segment for the payment order/remittance advice used in ASC X12-based syntax to indicate
the beginning of a payment-related transaction set that contains the necessary banking information to
process the transaction.

DNE: Addenda Records contains the following NACHA endorsed banking convention starting in position
04:

DATE OF DEATH*MMDDYY*CUSTOMERSSN*
#########*AMOUNT*$$$$.cc\

The date of death always appears in positions 18-23. If the Social Security Number (SSN) is not available,
positions 38-46 contain zeros. The amount of the expected beneficiary payment always begins in position
55.

ENR: This field contains the following NACHA endorsed banking convention:

 ll information in this field pertains to the account holder on whose behalf the Automated Enrollment
A
Entry is initiated.

ORlviii 2 0 1 3 O P E R AT I N G R U L E S
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

Transaction Code – This field contains the Transaction Code of the account holder’s account. This field
contains “22” (Demand Credit), “27” (Demand Debit), “32” (Savings Credit), or “37” (Savings Debit). (2
positions)

Receiving DFI Identification Number -- This field contains the routing number used to identify the DFI at
which the account holder maintains its account. (8 positions)

Check Digit – This field contains the check digit pertaining to the routing number for the DFI at which
the account holder maintains its account. (1 position)

DFI Account Number – This field contains the account holder’s account number. (1 - 17 positions)

Individual Identification Number/Identification Number – For automated enrollments initiated on behalf

of consumers, this field contains the consumer’s Social Security Number. For automated enrollments
initiated on behalf of companies, this field contains the company’s Taxpayer Identification Number. (9
positions)

Individual Name (Surname)/Company Name – This field contains the consumer’s surname or the first
fifteen characters of the Company Name. (1 - 15 positions)

Individual Name (First Name)/Company Name – This field contains the consumer’s first name or the next
seven characters of the Company Name. (1 - 7 positions).

Representative Payee Indicator/Enrollee Classification Code – For enrollments for Federal Government
benefit payments, this field contains “0” (zero) meaning “no” or “1” (one) meaning “yes” to denote whether
the authorization is being initiated by someone other than the named beneficiary.

For all other enrollments, this field contains “A” to indicate that the enrollee is a consumer, or “B” to
indicate that the enrollee is a company. (1 position)

For Example:

22*12200004*3*123987654321*777777777*DOE*JOHN*0\
22*12200004*3*987654321123*876543210*ABCCOMPANY**B\
27*12200004*3*987654321123*876543210*ABCELECTRONICIN*DUSTRIE*B\

IAT: This field contains 80 characters of payment related information. (Note: A maximum of two optional
Addenda Records may be used for IAT remittance information.)

When the Transaction Type Code Field within the First IAT Addenda Record contains ARC, BOC, or RCK,
this field must contain the Check Serial Number starting in position 04:

CHECK SERIAL NUMBER\

For example: 3349809002\

When the Transaction Type Code Field within the First IAT Addenda Record contains POP, this field must
contain the following NACHA-endorsed banking convention starting in position 04:

CHECK SERIAL NUMBER (MAXIMUM OF 9 CHARACTERS)*TERMINAL CITY (MAXIMUM OF 4

CHARACTERS)*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\

2 0 1 3 O P E R AT I N G R U L E S ORlix
 S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S

For example: 123456789*PARI*FR\

When the Transaction Type Code Field within the First IAT Addenda Record contains MTE, POS, or SHR,
this field must contain the following NACHA-endorsed banking convention starting in position 04:

TERMINAL IDENTIFICATION CODE(MAXIMUM OF 6 CHARACTERS)*TERMINAL LOCATION

(MAXIMUM OF 27 CHARACTERS)*TERMINAL CITY)MAXIMUM OF 15 CHARACTERS)
*TERMINAL  STATE/FOREIGN COUNTRY
(2 CHARACTERS)\

For example:

200509*321 EAST MARKET STREET*ANYTOWN*VA\

367802*10TH & VINE STREETS*LONDON*UK\

TRX: This field contains information formatted in accordance with National Association for Check
Safekeeping syntax.

APPENDIX THREE

ACH Record Format Specifications

u Please
refer to the following Sequence of Records for CCD Entries for changes related to Health Care EFT
Transactions.

ORlx 2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.8  Sequence of Records for CCD Entries

CCD ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA ADDENDA
ELEMENT RECORD TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION RECEIVING DISCRETIONARY RECORD TRACE
NAME TYPE CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER COMPANY NAME DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O R O M M

u Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric1 Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

CCD ADDENDA RECORD

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

u Contents ‘7’ ‘05’ Alphameric2 Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

u 1 For Health Care EFT Transactions, the Addenda Record Indicator of the CCD Entry must always contain a value of "1."
2 For Health Care EFT Transactions, the Payment Related Information Field of the CCD Entry Addenda Record must always contain the ASC X12 Version 5010 835 TRN Segment.

ORlxi
S U P P L E M E N T # 2 - 2 0 1 2 T O T H E N A C H A O P E R AT I N G R U L E S
 ARTICLE ONE – General Rules

Participating DFI reasonably believes that taking

such action in connection with a specific Entry
ARTICLE ONE would violate applicable U.S. Legal Requirements,
General Rules including the obligations of the Participating
DFI under programs administered by the U.S.
Department of the Treasury’s Office of Foreign
Assets Control (OFAC) and the Financial Crimes
SECTION 1.1 Application of Rules Enforcement Network (FinCEN). A Participating
These Rules apply to all Entries Transmitted DFI must comply with all other requirements of
through one or more ACH Operators, except as these Rules with respect to all other Entries or
provided in this Section 1.1. other aspects of the same Entry, including the
timely transmission of Return Entries and the
SUBSECTION 1.1.1  Conflicting Association availability of funds from Entries.
Rules Govern
These Rules may be superseded by any conflicting SUBSECTION 1.2.2  Audits of Rules Compliance
operating rules of an Association by which an A Participating DFI must annually conduct, or
ODFI and RDFI have agreed to be bound. have conducted, an audit of its compliance with
these Rules in accordance with Appendix Eight
SUBSECTION 1.1.2  Express Agreement of (Rule Compliance Audit Requirements).  A Third-
Federal Government Required Party Service Provider, including a Third Party
These Rules apply to Entries originated by a United Sender, that has agreed with a Participating DFI
States Government entity or agency only if the to process Entries must annually conduct, or have
United States Government has expressly agreed to conducted, an audit of its compliance with these
be bound by these Rules under 31 C.F.R. Part 210. Rules in accordance with Appendix Eight (Rule
Compliance Audit Requirements).
SUBSECTION 1.1.3  General and Specific Rules
If there is a conflict in these Rules between a SUBSECTION 1.2.3  Rules Enforcement
general provision applicable to all Entry types and A Participating DFI is subject to, and must comply
a specific provision applicable to a specific Entry with, the Rules enforcement procedures of the
type, the provision for the specific Entry type National Association contained in Appendix Ten
governs. Rules of general application are subject (Rules Enforcement).
to exceptions stated within these Rules. Specific
provisions, obligations, and exceptions for specific SUBSECTION 1.2.4  Risk Assessments
SEC Codes or other Entry types are described in A Participating DFI must:
the sections and subsections for those Entry types.
(a) conduct, or have conducted, an assessment
SECTION 1.2  Participating DFIs Must of the risks of its ACH activities;
Comply With Rules
A Participating DFI must comply with these Rules (b) 
implement, or have implemented, a risk
and warrants that it is legally able to comply with management program on the basis of such
all applicable requirements of these Rules. Only an assessment; and,
Participating DFIs may be ODFIs and RDFIs. A
(c) 
comply with the requirements of its
Participating DFI is responsible for its Third-Party
regulator(s) with respect to such assessment
Service Providers’ compliance with these Rules.
and risk management program.
SUBSECTION 1.2.1  Effect of Illegality
SUBSECTION 1.2.5  Compensation for Errors
Nothing in these Rules requires a Participating DFI
The settlement of claims for compensation
to debit or credit an account or to transfer funds
between Participating DFIs may be governed
or take other action required by the Rules if the
by the procedures contained in Appendix Seven
(Compensation Rules).

2 0 1 3 O P E R AT I N G R U L E S OR1
ARTICLE ONE – General Rules

SUBSECTION 1.2.6  Arbitration these Rules. Such written interpretations apply

The settlement of disputes between Participating and are binding as if they were set forth in full in
DFIs arising under these Rules may be governed these Rules and were adopted in accordance with
by the procedures contained in Appendix Nine Subsection 1.3.1 (Procedures for Amending the
(Arbitration Procedures). Rules).

SECTION 1.3  Amending, Suspending SUBSECTION 1.3.4  Construction Rules

and Interpreting the Rules Words in a singular number include the plural,
and in the plural include the singular, unless the
SUBSECTION 1.3.1  Procedures for Amending context otherwise requires. The term “section”
the Rules refers to a subdivision of an Article containing a
These Rules may be amended by action of the two-digit number (e.g., “Section 3.2”), and the term
eligible voting members of the National Association “subsection” refers to a subdivision of a section
in accordance with the procedures set forth in the containing a three or four-digit number (e.g.,
bylaws of the National Association. These Rules “Subsection 3.2.1”). The term “part” refers to a
may be amended by a vote of either (a) two-thirds of subdivision of an Appendix (e.g., “Part 3.2”), and
the total number of votes cast by eligible members, the term “subpart” refers to a subdivision of a part
or (b) three-quarters of the number of members (e.g., “Subpart 3.2.1”). Terms that are defined in
eligible to vote, unless, in either case, two-thirds of Article Eight (Definitions of Terms Used in These
the eligible members of a membership class vote Rules) and file format data elements contained
against the amendment. Amendments must be in Appendix Three, Subpart 3.2.2 (Glossary of
submitted to the eligible voting members by mail, Data Elements) are capitalized (e.g., “Entry” and
fax, or e-mail. A member’s ballot must by received “Addenda Type Code”) throughout these Rules.
by the National Association no later than fifteen
Business Days after the date of the ballot, or such SUBSECTION 1.3.5  Headings and Captions
later date as is specified in connection with the Headings and captions in these Rules are intended
ballot. Each approved amendment will become only for convenience of reference and have no
effective on the date indicated in the ballot on the substantive effect.
amendment.
SECTION 1.4  Records
SUBSECTION 1.3.2  Temporary Adoption,
Suspension, or Change of Effective Date of Rules SUBSECTION 1.4.1  Retention Requirement for
Records of Entries
The Board of Directors of the National Association
may approve an amendment to these Rules, A Participating DFI must retain a Record of
suspend an amendment to these Rules, or change each Entry for six years from the date the Entry
the effective date of an amendment to these was Transmitted, except as otherwise expressly
Rules if it determines that such action is in the provided in these Rules.
best interests of the National Association and its
members. Any such action taken by the Board of SUBSECTION 1.4.2  Provision Requirement for
Directors will remain effective as provided by the Records of Entries
Board of Directors until the earlier of (a) further A Participating DFI must, if requested by its
action by the Board of Directors, or (b) action customer or any other Participating DFI or ACH
taken by the eligible voting members to amend Operator that originated, Transmitted, or received
the Rules in accordance with Subsection 1.3.1 the Entry, provide the requester with a printout
(Procedures for Amending the Rules). or reproduction of the information relating to the
Entry. A Participating DFI may impose a reasonable
SUBSECTION 1.3.3  Official Interpretation of charge for providing such information.
the Rules
The Board of Directors of the National Association
may issue written interpretations of these Rules
that are consistent with the express language of

OR2 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE ONE – General Rules

SUBSECTION 1.4.3  Electronic Record Creation information, be either encrypted or Transmitted via
and Retention a secure session, in either case using a commercially
A Record required by these Rules to be in writing reasonable technology that provides a level of
may be created or retained in an Electronic form security that, at a minimum, is equivalent to 128-bit
that (a) accurately reflects the information in the RC4 encryption technology. Banking information
Record, and (b) is capable of being accurately includes any Entry, routing number, account
reproduced for later reference, whether by number, PIN or other identification symbol. This
Transmission, printing, or otherwise. Section applies to Transmissions between:

SUBSECTION 1.4.4 Electronic Signatures (a) a Receiver and an Originator;

A Record that is required by these Rules to be (b) an Originator and an ODFI;
signed or similarly authenticated may be signed
(c) an ODFI and an ACH Operator;
with an Electronic Signature in conformity with
the terms of the Electronic Signatures in Global (d) an ACH Operator and an RDFI; and
and National Commerce Act (15 U.S.C. § 7001, et (e) an Originator, ODFI, RDFI, or ACH Operator
seq.), including the provisions that reference state and a Third-Party Service Provider.
versions of the Uniform Electronic Transactions
Act, and in a manner that evidences the identity of Transmissions of banking information over an
the Person who signed and that Person’s assent to Unsecured Electronic Network by means of voice
the terms of the Record. or keypad inputs from a wireline or wireless
telephone to a live operator or voice response unit
SECTION 1.5  Excused Delay are not subject to this section.
Delay by a Participating DFI or ACH Operator
beyond the time limits prescribed or permitted SECTION 1.7  Choice of Law
by these Rules is excused to the extent the delay These Rules and the rights and obligations of
was caused by the interruption of communication a party with regard to a credit Entry subject to
or computer facilities, provided that the delay is Article 4A of the Uniform Commercial Code are
beyond the reasonable control of the Participating construed in accordance with and governed by the
DFI or ACH Operator. This may include delays laws of the State of New York, unless otherwise
caused by war or act of God, provided that the provided in an agreement by which the relevant
Participating DFI or ACH Operator exercises such parties are bound.
diligence as the circumstances require. Delay
caused by the general failure of a Participating
SECTION 1.8  Beneficiaries of the Rules
DFI’s, or its Third-Party Service Provider’s, computer
facilities or other equipment does not constitute an Each Participating DFI, ACH Operator, Association,
excused delay and should be addressed within the and the National Association (including its Board,
Participating DFI’s contingency planning policies. committees, and panels) are intended third-party
Delay by an ACH Operator beyond the time limits beneficiaries of the representations, warranties,
prescribed or permitted by these Rules also is and covenants of each other Participating DFI and
excused to the extent the delay was caused by the ACH Operator under these Rules. Nothing in these
interruption or the suspension of payment by, or Rules is intended to, and nothing in these Rules
unavailability of funds from, a Participating DFI or is implied to, give any legal or equitable right,
another ACH Operator. remedy, or claim to any other entity, including
to any Originator, Receiver, Third-Party Service
Provider, or Third-Party Sender.
SECTION 1.6  Secure Transmission
of ACH Information Via Unsecured
Electronic Networks SECTION 1.9  Protection for the National
Association from Frivolous Lawsuits
Banking information related to an Entry that is
Transmitted via an Unsecured Electronic Network A Participating DFI that commences a legal
must, at all times from the point of data entry proceeding against the National Association must
and through the Transmission of such banking pay, on demand, the attorneys’ fees and costs

2 0 1 3 O P E R AT I N G R U L E S OR3
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

incurred by the National Association in connection SUBSECTION 2.2.1  ODFI Agreement with
with the proceeding if judgment is rendered in Originator, Third Party Sender or Sending Point
the National Association’s favor or if the National SUBSECTION 2.2.1.1  ODFI Must Enter Origination
Association is otherwise dismissed from the Agreement with Originator
proceeding. An ODFI must enter into an Origination Agreement
with each Originator for which the ODFI will
SECTION 1.10  Network Administration originate Entries. The Origination Agreement
Fees must include, at a minimum, each of the following:
A Participating DFI agrees to pay the National
Association (a) an annual fee, and (b) a per-Entry (a) The Originator must authorize the ODFI to
fee for each Entry that is Transmitted or received originate Entries on behalf of the Originator
by the Participating DFI, including those Entries to Receivers’ accounts;
that are not processed through an ACH Operator
(b) The Originator must agree to be bound by
but are exchanged with another non-affiliated
these Rules;
Participating DFI. The annual and per-Entry fees
are established from time-to-time by the Board
(c) The Originator must agree not to originate
of Directors of the National Association and are
Entries that violate the laws of the United
published within the Schedule of Fees part of the
States;
Rules.
(d) Any restrictions on the types of Entries that
may be originated;
ARTICLE TWO
(e) 
The right of the ODFI to terminate or
Rights and suspend the agreement for breach of these

Responsibilities Rules in a manner that permits the ODFI to

comply with these Rules; and,

of ODFIs, Their (f) 

The right of the ODFI to audit the

Originators and Originator’s compliance with

Origination Agreement and these Rules.
the

Third-Party Senders SUBSECTION 2.2.1.2  ODFI Must Enter Origination

Agreement with Third-Party Sender
An ODFI must enter into an Origination Agreement
SECTION 2.1  General Rule – ODFI with each Third-Party Sender for which the ODFI
is Responsible for Entries and Rules will originate Entries. The Origination Agreement
Compliance must include each of the following:
An ODFI is responsible for all Entries originated
through the ODFI, whether by an Originator or (a) 
The Third-Party Sender, on behalf of the
through a Third-Party Sender, including Entries Originator, must authorize the ODFI to
Transmitted through Direct Access. An ODFI is originate Entries on behalf of the Originator
responsible for its Originators’ and Third-Party to Receivers’ accounts;
Senders’ compliance with these Rules.
(b) The Third-Party Sender must agree to be
SECTION 2.2  Prerequisites to bound by these Rules;
Origination
(c) The Third-Party Sender must agree not to
An ODFI must perform, or ensure that an originate Entries that violate the laws of the
Originator or Third-Party Sender performs, each United States;
of the following before permitting the Originator
or Third-Party Sender to originate any Entry: (d) Any restrictions on the types of Entries that
may be originated;

OR4 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

(e) 
The right of the ODFI to terminate or (ii) 
Enforce restrictions on the types of
suspend the agreement, or any Originator Entries that may be originated; and
of the Third-Party Sender, for breach of
these Rules in a manner that permits the (iii) Enforce the exposure limit.
ODFI to comply with these Rules;
SUBSECTION 2.2.2.1  Termination, Suspension, and
(f) The right of the ODFI to audit the Third-Party Audit of Originators and Third-Party Senders
Sender’s and its Originators’ compliance In addition to any other termination or suspension
with the Origination Agreement and these rights in an Origination Agreement, including for
Rules; and breach, if an Originator or Third-Party Sender
breaches these Rules, or causes its ODFI to breach
(g) 
The Third-Party Sender must agree that, these Rules, the Origination Agreement may be
before permitting an Originator to originate terminated or suspended by the ODFI upon ten
any Entry directly or indirectly through the Banking Days’ notice, or such shorter notice period
ODFI, it will enter into an agreement with as may be provided in the Origination Agreement.
the Originator that satisfies each of the In addition to any other audit rights that may be
requirements of Subsection 2.2.1.1 (ODFI set forth in an Origination Agreement, the ODFI
Must Enter Origination Agreement with may audit the compliance of the Originator or
Originator). Third-Party Sender with these Rules and the
Origination Agreement, subject to the procedural
SUBSECTION 2.2.1.3  ODFI Agreement with requirements, if any, set forth in the Origination
Sending Points Agreement.
An ODFI must enter into an agreement with each
Sending Point that Transmits Entries on the ODFI’s SUBSECTION 2.2.3  ODFI Board Approval of
behalf to an ACH Operator. The ODFI is liable for Direct Access Debit Participants
each Entry Transmitted by the Sending Point that An ODFI’s board of directors, committee of the
contains the ODFI’s routing number. board of directors, or its designee must approve a
Direct Access Debit Participant relationship prior
SUBSECTION 2.2.2  ODFI Risk Management to the ODFI originating Entries for the Direct
An ODFI must perform due diligence with respect Access Debit Participant.
to the Originator or Third-Party Sender sufficient
to form a reasonable belief that the Originator or SECTION 2.3  Authorization and Notice
Third-Party Sender has the capacity to perform its of Entries
obligations in conformance with these Rules.
SUBSECTION 2.3.1  General Rule – Originator
In addition, the ODFI must: Must Obtain Authorization from Receiver
An Originator must obtain authorization from the
(a) 
Assess the nature of the Originator’s or Receiver to originate one or more Entries to the
Third-Party Sender’s ACH activity and the Receiver’s account.
risks it presents;
SUBSECTION 2.3.2   Authorizations and Notices
(b) 
Establish, implement, and periodically with Respect to Consumer Accounts
review an exposure limit for the Originator
or Third-Party Sender; and SUBSECTION 2.3.2.1  Credit Entries
Authorization of a credit Entry to a Consumer
(c) Establish and implement procedures to: Account is not required to be in writing. If both
the Originator and Receiver are natural Persons,
(i) 
Monitor the Originator’s or Third- no authorization by the Receiver is required, and
Party Sender’s origination and return no warranty with respect to any such authorization
activity across multiple Settlement is made by the ODFI.
Dates;

2 0 1 3 O P E R AT I N G R U L E S OR5
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.3.2.2  Debit Entries Commerce Act (15 U.S.C. §7001 et seq.). An
(a) 
Authorization of a debit Entry to a Electronic authorization must be visually displayed
Consumer Account must be in writing and in a manner that enables the consumer to read the
signed or similarly authenticated by the communication.
Receiver, except as expressly provided in
the authorization sections of these Rules for SUBSECTION 2.3.2.5  Retention and Provision of
specific types of Entries. Where these Rules the Record of Authorization
provide that authorization for an Entry (a) 
An Originator must retain the original
may be obtained by notice to the Receiver, or a copy of each written authorization
authorization also may be obtained by of a Receiver, or a readily and accurately
means of a signed written authorization reproducible Record evidencing any
that meets the requirements of Subsection other form of authorization, for two years
2.3.2.3 (Form of Authorization) if all of the from the termination or revocation of the
other requirements for the type of Entry authorization.
are met.
(b) U
 pon receipt of an RDFI’s written request,
(b) 
An Originator must provide each Receiver the ODFI must provide the original, copy
with an Electronic or hard copy of the or other accurate Record of the Receiver’s
Receiver’s authorization for all debit Entries authorization to the RDFI within ten
to be initiated to a Consumer Account. Banking Days without charge.

SUBSECTION 2.3.2.3  Form of Authorization (c) At the request of its ODFI, the Originator
An authorization must: must provide the original, copy or
other accurate Record of the Receiver’s
(a) be readily identifiable as an authorization; authorization to the ODFI for its use or
for the use of an RDFI requesting the
(b) 
have clear and readily understandable information. The Originator must provide
terms. A purported authorization that is not the original, copy or other accurate Record
clear and readily understandable as to its in such time and manner as to enable the
terms (including the amount or timing of ODFI to deliver the authorization to a
debits), or that is otherwise invalid under requesting RDFI within ten Banking Days
applicable Legal Requirements, does not of the RDFI’s request.
satisfy the requirements of this Section 2.3;
and SUBSECTION 2.3.2.6  Notices of Variable Debits to
Consumer Accounts
(c) 
provide that the Receiver may revoke Notice of Change in Amount.
(a)  If the
the authorization only by notifying the amount of a debit Entry to be initiated
Originator in the time and manner stated to a Consumer Account differs from the
in the authorization. For a Single Entry amount of the immediately preceding debit
scheduled in advance, any such revocation Entry relating to the same authorization, or
right shall afford the Originator a reasonable differs from a preauthorized amount, an
opportunity to act on such revocation prior Originator must send the Receiver written
to the initiation of the Entry. notification of the amount of the Entry and
the date on or after which the Entry will be
SUBSECTION 2.3.2.4  Electronic Authorizations debited at least ten calendar days prior to
The writing and signature requirements of the date on which the Entry is scheduled to
Subsection 2.3.2.2(a) (Authorization and Notices be initiated.
with Respect to Consumer Accounts – Debit
Entries) may be satisfied by compliance with No Notice Required for Change Within
(b) 
the Electronic Signatures in Global and National Agreed Range. The Originator is not
required to give the notice in Subsection

OR6 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

2.3.2.6(a) (Notice of Change in Amount) and the ODFI have agreed that the laws of
above if (i) the Originator provides, and another jurisdiction govern their rights and
the Receiver chooses, the option to receive obligations;
such notice only if the amount of the Entry
falls outside a specified range or if the (c) credit given by the RDFI to the Receiver for
Entry differs from the most recent Entry by the Entry is provisional until the RDFI has
more than an agreed upon amount, and (ii) received final settlement through a Federal
the variation in the amount of the Entry Reserve Bank or otherwise has received
is within the tolerance agreed to by the payment as provided for in Section
Receiver. 4A-403(a) of Article 4A; and

Notice of Change in Scheduled Debiting

(c)  (d) if the RDFI does not receive such payment
Date. An Originator that changes the for the Entry, the RDFI is entitled to a
scheduled date on or after which debit refund from the Receiver in the amount of
Entries are to be initiated to a Receiver’s the credit to the Receiver’s account, and the
account must send to the Receiver written Originator will not be considered to have
notification of the new date on or after paid the amount of the credit Entry to the
which Entries are scheduled to be debited Receiver.
to the Receiver’s account. The Originator
must send such notification to the Receiver uSUBSECTION 2.3.4 Restrictions on Data Passing
at least seven calendar days before the first An ODFI must not disclose, and must ensure
such Entry is scheduled to be debited to that the Originator and any Third Party Service
the Receiver’s account. For purposes of this Provider acting on behalf of the Originator or ODFI
subsection, variation in debiting dates due do not disclose, the Receiver’s account number or
to Saturdays, Sundays, or holidays are not routing number to any third party for such third
considered to be changes in the scheduled party’s use, directly or indirectly, in initiating a
dates. separate debit Entry.

SUBSECTION 2.3.3  Agreement and Notice for SECTION 2.4   General Warranties and
Entries to Non-Consumer Accounts
Liabilities of Originating Depository
SUBSECTION 2.3.3.1  Agreement to be Bound Financial Institutions
by the Rules
SUBSECTION 2.4.1  General ODFI Warranties
The Originator must obtain the Receiver’s
An ODFI Transmitting an Entry warrants the
agreement to be bound by these Rules.
following to each RDFI and ACH Operator in
connection with such Entry at the time of the
SUBSECTION 2.3.3.2  Notice by ODFI to Originator
Entry’s Transmission by or on behalf of the ODFI,
for Non-Consumer Credit Entries
unless another effective time frame is provided in
For a credit Entry subject to Article 4A, an ODFI this Subsection 2.4.1.
must provide the Originator with notice, as part of
the Origination Agreement or otherwise, of each
SUBSECTION 2.4.1.1  The Entry is Authorized by the
of the following: Originator and Receiver
(a) 
The Entry has been properly authorized
(a) the Entry may be Transmitted through the
by the Originator and the Receiver in
ACH;
accordance with these Rules.
(b) the rights and obligations of the Originator
(b) 
The Originator’s authorization has not
concerning the Entry are governed by and
been revoked, the Origination Agreements
construed in accordance with the laws of
concerning the Entry have not been
the State of New York, unless the Originator
terminated, and neither the ODFI, any

uApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR7
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Third-Party Sender, nor the Originator SUBSECTION 2.4.1.6  Debit Entry Satisfies an
has actual knowledge of the revocation Obligation or Corrects an Error
of the Receiver’s authorization or of the The debit Entry is:
termination of the agreement between
the RDFI and the Receiver concerning the (a) for an amount that will be due and owing
Entry. to the Originator from the Receiver on the
Settlement Date;
(c) At the time the Entry is processed by an
RDFI, the authorization for that Entry (b) for a sum specified by the Receiver to be
has not been terminated, in whole or in paid to the Originator; or
part, by operation of law. This Subsection
2.4.1.1(c) shall not apply if the RDFI has (c) to correct a previous credit Entry that was
actual knowledge of the circumstances an Erroneous Entry.
giving rise to such termination at the time
it processes the Entry and the ODFI does SUBSECTION 2.4.1.7  Secure Transmission of
not have such actual knowledge. Banking Information
Banking information for the Entry is Transmitted
SUBSECTION 2.4.1.2  The Entry Complies with in compliance with the requirements of Section
the Rules 1.6 (Secure Transmission of ACH Information Via
The Entry complies with these Rules, including the Unsecured Electronic Networks).
use of the proper Standard Entry Class Code.
SUBSECTION 2.4.1.8  The ODFI has Verified the
SUBSECTION 2.4.1.3  The Entry is Not Transmitted Identity of Originator or Third-Party Sender That
on Behalf of a Suspended Originator or Third Party Uses an Unsecured Electronic Network
Sender The ODFI has utilized a commercially reasonable
The Entry is not Transmitted on behalf of any method to establish the identity of an Originator or
Originator or Third-Party Sender that the ODFI has Third-Party Sender that entered into an Origination
been directed to suspend or that appears on a list Agreement via an Unsecured Electronic Network.
of suspended Originators and Third-Party Senders
issued by the National Association from time to SUBSECTION 2.4.2  ODFI Warranties Do Not
time, in each case in accordance with Appendix Apply to Goods or Services
Ten, Subpart 10.4.7.6 (Suspension). The warranties contained within Subsection 2.4.1
(General ODFI Warranties) and the requirements
SUBSECTION 2.4.1.4  The Entry Contains of Subsection 2.3.1 (General Rule - Originator
Required Information Must Obtain Authorization from Receiver) do not
The Entry contains the Receiver’s correct account apply to the goods or services to which the Entry
number and all other information necessary to relates.
enable the RDFI to comply with the requirements
of Subsection 3.1.5 (RDFI Obligation to Provide SUBSECTION 2.4.3  ODFI Warranties for Entries
Information About Entries), except for information Through its Sending Points
within the purview of the RDFI’s relationship with An ODFI using a Sending Point to Transmit Entries
the Receiver. All information Transmitted with the to an ACH Operator shall be deemed to have made
Entry is related to the payment represented by the the warranties of Subsection 2.4.1 (General ODFI
Entry. Warranties) for each Entry containing the ODFI’s
routing number that is Transmitted by the Sending
SUBSECTION 2.4.1.5  Credit Entry is Timely Point, regardless of whether the Sending Point was
The credit Entry is timely. authorized by the ODFI to Transmit the Entry.

OR8 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.4.4  General Indemnity by ODFI SUBSECTION 2.5.1.2  Authorization of ARC Entries
by Notification
SUBSECTION 2.4.4.1  Indemnity for Breach of An Originator may satisfy the requirement for
Warranty authorization of an ARC Entry by providing the
An ODFI shall indemnify every RDFI and ACH Receiver a notice meeting the requirements of this
Operator from and against any and all claims, subsection and obtaining the Receiver’s Eligible
demands, losses, liabilities, and expenses, Source Document. The Originator must provide a
including attorneys’ fees and costs, that result conspicuous notice to the Receiver that includes the
directly or indirectly from (a) the breach of any following, or substantially similar, language prior
warranty made to such party by the ODFI under to the receipt of each Eligible Source Document
these Rules, or (b) the debiting or crediting of that is used to initiate an ARC Entry:
an Entry to a Receiver’s account in accordance
with the terms of the Entry, including any claims, “When you provide a check as
demands, losses, liabilities, or expenses, and/or payment, you authorize us either to use
attorneys’ fees and costs that result, either directly information from your check to make a
or indirectly, from the return of one or more items one-time electronic fund transfer from
or Entries of the Receiver due to insufficient funds your account or to process the payment
caused by a debit Entry. as a check transaction.”

SUBSECTION 2.4.4.2  Indemnity for Failure to The Originator must provide a copy of the notice,
Comply with Regulation E or language that is substantially similar, to the
An ODFI shall indemnify every RDFI and ACH Receiver at the time of the transaction when the
Operator from and against any claims, demands, Eligible Source Document for the Entry is provided
losses, liabilities, or expenses, including attorneys’ by the Receiver in-person for payment of a bill at
fees and costs, based on the ground that the failure a manned location.
of the ODFI to comply with any provision of these
Rules resulted, either directly or indirectly, in the The requirements of Subsection 2.3.2.3(c) (Form
violation by an RDFI of the Federal Electronic of Authorization) concerning revocation of
Fund Transfer Act or Federal Reserve Board authorization do not apply to an ARC Entry.
Regulation E.
For an ARC Entry to a non-Consumer Account,
SECTION 2.5  Provisions for Specific Subsection 2.3.3.1 (Agreement to be Bound by the
Types of Entries Rules) does not apply.

SUBSECTION 2.5.1  Specific Provisions for ARC SUBSECTION 2.5.1.3  Eligible Source
Entries (Accounts Receivable Entry) Document Required
An Originator must use an Eligible Source
SUBSECTION 2.5.1.1  General Rule for ARC Entries Document provided by the Receiver as the source
An ARC Entry is a Single Entry debit originated for the Receiver’s routing number, account number,
based on an Eligible Source Document provided Check Serial Number, and dollar amount for an
to an Originator by a Receiver (1) via U.S. mail or ARC Entry.
delivery service, (2) at a dropbox location, or (3) in
person for payment of a bill at a manned location. SUBSECTION 2.5.1.4  Capture of Banking
An ODFI must perform, or ensure that its Originator Information
or Third-Party Sender performs, the requirements An Originator must initially use a reading device
of Subsection 2.5.1.2 (Authorization of ARC Entries to capture the Receiver’s routing number, account
by Notification), Subsection 2.5.1.3 (Eligible Source number, and Check Serial Number from the MICR
Document Required) and Subsection 2.5.1.4 line of the Receiver’s Eligible Source Document.
(Capture of Banking Information) below before The Originator may key-enter such information
permitting the Originator or Third-Party Sender to only to correct errors resulting from MICR
originate an ARC Entry. misreads, misencoding, or processing rejects.

2 0 1 3 O P E R AT I N G R U L E S OR9
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.5.1.5  Additional ODFI Warranties Entry, clearly marked on its face as a copy,
for ARC Entries to the RDFI within ten Banking Days upon
In addition to the other warranties contained receiving written request from the RDFI,
within these Rules, an ODFI originating an ARC provided that such request is received
Entry warrants to each RDFI and ACH Operator, within two years of the Settlement Date of
that: the ARC Entry.

(a) Entry Information is Accurate. The SUBSECTION 2.5.2  Specific Provisions for BOC
amount of the ARC Entry, the routing Entries (Back Office Conversion Entry)
number, the account number, and the
Check Serial Number accurately represent SUBSECTION 2.5.2.1  General Rule for BOC Entries
the information on the Eligible Source A BOC Entry is a Single Entry debit originated
Document used to initiate the ARC Entry. based on an Eligible Source Document provided to
an Originator by a Receiver at the point-of-purchase
(b) Eligible Source Document Will Not Be or manned bill payment location for subsequent
Presented for Payment. The Eligible conversion during back-office processing. A BOC
Source Document used to initiate the ARC Entry may be used only for an in-person transaction
Entry will not be presented or returned for which there is no standing authorization with
such that any Person will be required the Originator for the origination of Entries to the
to make payment based on the Eligible Receiver’s account. An ODFI must perform, or
Source Document, unless the ARC Entry is ensure that its Originator or Third-Party Sender
returned by the RDFI. performs, the requirements of Subsection 2.5.2.2
(Authorization of BOC Entries by Notification),
(c) 
Retention of Copy of Eligible Source Subsection 2.5.2.3 (Eligible Source Document
Document and Related Payment Data Required), and Subsection 2.5.2.4 (Capture of
by Originator. The Originator will retain Banking Information) below before permitting the
a reproducible and legible copy of the Originator or Third-Party Sender to initiate a BOC
front of the Receiver’s Eligible Source Entry.
Document used to initiate each ARC Entry
for two years from the Settlement Date of SUBSECTION 2.5.2.2  Authorization of BOC Entries
the ARC Entry, and will provide it to the by Notification
ODFI upon request for use in complying An Originator may satisfy the requirement for
with Subsection 2.5.1.5(d) (Provision of authorization of a BOC Entry by providing the
Copy of Eligible Source Document to Receiver a notice meeting the requirements of this
RDFI) below. The Originator will establish subsection and obtaining the Receiver’s Eligible
and implement commercially reasonable Source Document. The Originator must provide a
methods to securely store: conspicuous notice to the Receiver that includes the
following, or substantially similar, language prior
(i) 
the Eligible Source Document used to the receipt of each Eligible Source Document
to initiate the ARC Entry until it is that is used to initiate each BOC Entry:
securely destroyed; and
“When you provide a check as
(ii) all banking information relating to the payment, you authorize us either to use
ARC Entry. information from your check to make a
one-time electronic fund transfer from
Provision of Copy of Eligible Source
(d)  your account or to process the payment
Document to RDFI. The ODFI will provide as a check transaction. For inquiries,
a copy of the front of the Receiver’s Eligible please call <retailer phone number>.”
Source Document used to initiate the ARC
The Originator must post the notice in a prominent
and conspicuous location and must provide a copy

OR10 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

of such notice, or language that is substantially (i) company name;

similar, to the Receiver at the time of the transaction.
(ii) address;
The requirements of Subsection 2.3.2.3(c) (Form (iii) telephone number;
of Authorization) concerning revocation of
(iv) contact person;
authorization do not apply to a BOC Entry.
(v) taxpayer identification number; and
For a BOC Entry to a non-Consumer Account,
(vi) 
a description of the nature of the
Subsection 2.3.3.1 (Agreement to be Bound by the
business of each Originator.
Rules) does not apply.
(c) 
Provision of Originator Information to
SUBSECTION 2.5.2.3  Eligible Source
RDFI. The ODFI has established and
Document Required
implemented practices and procedures
An Originator must use an Eligible Source to provide the RDFI with information
Document provided by the Receiver at the point identifying the Originator of BOC Entries
of purchase or manned bill payment location as within two Banking Days of receipt of the
the source document for the Receiver’s routing RDFI’s written request for such information,
number, account number, Check Serial Number, provided the RDFI’s written request is
and dollar amount for a BOC Entry. received within two years of the Settlement
Date of the original BOC Entry.
SUBSECTION 2.5.2.4  Capture of Banking
Information (d) 
Verification of Receiver’s Identity. The
An Originator must initially use a reading device Originator has established and implemented
to capture the Receiver’s routing number, account commercially reasonable procedures to
number, and Check Serial Number from the MICR verify the identity of the Receiver.
line of the Receiver’s Eligible Source Document.
The Originator may key-enter such information (e) Customer Service Telephone Number. The
only to correct errors resulting from MICR Originator has established and maintains
misreads, misencoding, or processing rejects. a working telephone number that is
answered during normal business hours for
SUBSECTION 2.5.2.5  Additional ODFI Warranties Receiver inquiries regarding the BOC Entry
for BOC Entries and has displayed this telephone number
In addition to the other warranties contained on the notice required by Subsection
within these Rules, an ODFI originating a BOC 2.5.2.2 (Authorization of BOC Entries by
Entry warrants to each RDFI and ACH Operator Notification).
that:
(f) E
 ntry Information is Accurate. The
(a) 
Verification of Identity of Originator amount of the BOC Entry, the routing
or Third-Party Sender. The ODFI has number, the account number, and the
established and implemented commercially Check Serial Number accurately represent
reasonable procedures to verify the identity the information on the Eligible Source
of the Originator or Third-Party Sender of Document used to initiate the BOC Entry.
the BOC Entry.
(g) Eligible Source Document Will Not Be
(b) Documentation of Originators. The Presented for Payment. The Eligible
ODFI has established and implemented Source Document used to initiate the BOC
procedures to maintain the following Entry will not be presented or returned
information with respect to the Originator such that any person will be required
of the BOC Entry: to make payment based on the Eligible
Source Document, unless the BOC Entry is
returned by the RDFI.

2 0 1 3 O P E R AT I N G R U L E S OR11
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

(h) Retention of Eligible Source Document and SUBSECTION 2.5.4.2  ODFI to Satisfy Periodic
Related Payment Data by Originator. Each Statement Requirement
Originator will retain a reproducible and An ODFI must provide or make available the
legible copy of the front of the Receiver’s following information with respect to the Consumer
Eligible Source Document used to initiate Account of the Originator of a CIE Entry:
each BOC Entry for two years from the
Settlement Date of the BOC Entry, and will (a) posting date to the Originator’s account;
provide it to the ODFI upon request for
use in complying with Subsection 2.5.2.5(i) (b) dollar amount of the Entry;
(Provision of Copy of Eligible Source
Document to RDFI) below. The Originator (c) payee name;
will establish and implement commercially
reasonable methods to securely store: (d) Entry description;

(i) 
the Eligible Source Document used (e) account type;
to initiate the BOC Entry until it is
securely destroyed; and (f) account number;

(ii) all banking information relating to the (g) amount of any charges assessed against the
BOC Entry. account for services related to the Entry;

(i) P
 rovision of Copy of Eligible Source (h) balances in the Originator’s account at the
Document to RDFI. The ODFI will provide beginning and at the close of the statement
a copy of the front of the Receiver’s Eligible period; and
Source Document used to initiate the BOC
Entry, clearly marked on its face as a copy, (i) address and telephone number to be used
to the RDFI within ten Banking Days upon for inquiries or notices of errors preceded
receiving written request from the RDFI, by “Direct Inquiries To” or similar language.
provided that such request is received
within two years of the Settlement Date of References to data elements contained in an Entry
the BOC Entry. are further defined in Appendix Three (ACH
Record Format Specifications). The requirements
SUBSECTION 2.5.3  General Rule for CCD Entries of this subsection apply regardless of whether
(Corporate Credit or Debit Entry) Regulation E imposes similar requirements on the
A CCD Entry is originated by an Organization to or ODFI.
from the account of that Organization or another
Organization. A CCD Entry may be a credit Entry SUBSECTION 2.5.4.3  Rules That Do Not Apply to
CIE Entries
or a debit Entry, and may provide payment related
information in one Addenda Record. A CCD Entry The following subsections do not apply to CIE
may also be a Non-Monetary Entry that carries Entries:
payment related information in one Addenda
Record. (a) 
Subsection 2.2.1.1 (ODFI Must Enter
Origination Agreement with Originator);
SUBSECTION 2.5.4  Specific Provisions for CIE and
Entries (Customer Initiated Entry)
(b) Subsection 2.2.2 (ODFI Risk Management).
SUBSECTION 2.5.4.1  General Rule for CIE Entries
A CIE Entry is a credit Entry initiated by or on SUBSECTION 2.5.5  General Rule for CTX Entries
behalf of the holder of a Consumer Account to the (Corporate Trade Exchange Entry)
account of a Receiver. A CTX Entry is originated by an Organization to or
from the account of that Organization or another

OR12 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Organization. A CTX Entry may be a credit Entry SUBSECTION 2.5.8.3  Origination Agreements for
or a debit Entry that provides payment related IAT Entries
information in one or more Addenda Records. A An Origination Agreement between an ODFI and
CTX Entry may also be a Non-Monetary Entry that an Originator or Third-Party Sender for IAT Entries
carries information related to the payment in one must specify, in addition to the requirements of
or more Addenda Records. Subsection 2.2.1 (ODFI Agreement with Originator,
Third Party Sender or Sending Point):
SUBSECTION 2.5.6  General Rule for DNE Entries
(Death Notification Entry) (a) the terms and conditions for the allocation
A DNE Entry is a Non-Monetary Entry that of gains, losses, and the assumption of risk
gives notice by an agency of the United States for foreign exchange conversion; and
Government to an RDFI of the death of a Receiver.
Only an agency of the United States Government (b) the rights and responsibilities of the ODFI
may originate a DNE Entry. in the event of an Erroneous Entry.

SUBSECTION 2.5.7  General Rule for ENR Entries SUBSECTION 2.5.8.4  Additional ODFI Warranties
(Automated Enrollment Entry) for Outbound IAT Entries
An ENR Entry is a Non-Monetary Entry that In addition to the other warranties contained within
enrolls a Person with an agency of the United these Rules, an ODFI initiating an Outbound IAT
States Government that will enable Entries to such Entry warrants to each RDFI, ACH Operator, and
Person’s account at a Participating DFI. An ENR Gateway:
Entry may be originated by a Participating DFI at
the request of an account holder at the Participating (a) Compliance with U.S. Legal Requirements.
DFI to an agency of the United States Government The Originator and ODFI are in compliance
that has agreed to receive the ENR Entry. with U.S. Legal Requirements with respect
to the IAT Entry, including their obligations
SUBSECTION 2.5.8  Specific Provisions for IAT under programs administered by the U.S.
Entries (International ACH Transaction) Department of the Treasury’s Office of
Foreign Assets Control (OFAC) and the
SUBSECTION 2.5.8.1  General Rule Financial Crimes Enforcement Network
An IAT Entry is an Inbound or Outbound debit or (FinCEN).
credit Entry that is part of a payment transaction
involving a Financial Agency’s office that is not (b) Compliance with Foreign Payment System
located in the territorial jurisdiction of the United Rules. The origination of the IAT Entry
States. complies with the laws and payment
system rules of the receiving country.
SUBSECTION 2.5.8.2 Authorization for Outbound
IAT Entries SUBSECTION 2.5.8.5  ODFI Indemnity of Gateway
An Outbound IAT Entry must be authorized for Breach of Warranty
as provided in Subsection 2.3.1 (General Rule An ODFI breaching any of the warranties
- Originator Must Obtain Authorization from contained within Subsection 2.5.8.4 (Additional
Receiver). The form and content of the foreign ODFI Warranties for Outbound IAT Entries) shall
receiver’s authorization, including whether such indemnify each Gateway from and against any
authorization may be oral, electronic or written, is and all resulting claim, demand, loss, liability,
governed by the laws and payment system rules of or expense, including attorneys’ fees and costs,
the receiving country. For an Outbound credit IAT resulting directly or indirectly from the breach of
Entry for which both the Originator and foreign such warranties. The indemnification obligation of
receiver are natural Persons, no authorization is this Subsection 2.5.8.5 is in addition to the ODFI’s
required by these Rules. indemnification obligations under Subsection 2.4.4
(General Indemnity by ODFI).

2 0 1 3 O P E R AT I N G R U L E S OR13
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.5.8.6  Rules Exceptions for SUBSECTION 2.5.9  Specific Provisions for MTE
Outbound IAT Entries Entries (Machine Transfer Entry)
The following sections do not apply to Outbound
IAT Entries: SUBSECTION 2.5.9.1  General Rule
An MTE Entry is a credit or debit Entry initiated at
(a) 
Subsection 2.3.2 (Authorizations and an “electronic terminal,” as that term is defined in
Notices with Respect to Consumer Regulation E, to a Consumer Account maintained
Accounts); with an RDFI (i.e., an ATM cash deposit or
withdrawal).
(b) Subsection 2.3.3.1 (Agreement to be Bound
by the Rules); SUBSECTION 2.5.9.2  PIN Security
An ODFI and any Originator and Third-Party
(c) 
Section 2.10 (Reclamation Entries and Sender must comply with the American National
Written Demands for Payment); Standards Institute’s (ANSI) Accredited Standards
Committee (ASC) X9.8 concerning PIN Management
(d) Subsection 2.12.5.1 (Dishonor of Return by and Security with respect to the handling of any
ODFI). personal identification number (PIN) in connection
with the authorization of an MTE Entry.
The following sections apply to Outbound IAT
Entries to the extent supported by the laws and SUBSECTION 2.5.9.3  ODFI Warrants that the
payment system rules of the foreign receiving Originator has Satisfied Applicable PIN Requirements
country: If a personal identification number (PIN) is required
in connection with the authorization for an MTE
(e) Section 2.6 (Prenotifications); Entry, an ODFI warrants that the Originator has
complied with the American National Standards
(f) Section 2.8 (Reversing Files); Institute’s (ANSI) Accredited Standards Committee
(ASC) X9.8 concerning PIN Management and
(g) Section 2.9 (Reversing Entries);
Security. This provision does not apply if a card
issued by the ODFI or Originator of the Entry
(h) Section 2.11 (Notifications of Change);
is used in connection with the authorization for
these Entries.
(i) Subsection 2.12.4 (Reinitiation of Returned
Entries).
SUBSECTION 2.5.9.4  Rules Exceptions for
MTE Entries
The following sections apply to Outbound
IAT Entries only to the extent that the Uniform The following sections do not apply to MTE
Commercial Code Article 4A applies: Entries if the ODFI and the RDFI are parties to
an agreement (other than these Rules) for the
(j) 
Subsection 2.3.3.2(c) and (d) (Notice by provision of services related to MTE Entries:
ODFI to Originator for Non-Consumer
Credit Entries). (a) Subsection 2.3.2.5 (Retention and Provision
of the Record of Authorization);
SUBSECTION 2.5.8.7  Rules Exceptions for Inbound
IAT Entries (b) Subsection 2.5.9.2 (PIN Security);
The following subsection applies to Inbound IAT
(c) Subsection 2.5.9.3 (ODFI Warrants that the
Entries to the extent supported by the laws and
Originator has Satisfied Applicable PIN
payment system rules of the foreign originating
Requirements).
country:
The following sections do not apply to MTE Entries
(a) 
Subsection 2.11.1 (ODFI and Originator
if a card issued by the ODFI or Originator of the
Action on Notification of Change (NOC)).

OR14 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Entry is used in connection with the authorization your account or to process the payment
of the MTE Entries: as a check transaction.”

(d) Subsection 2.5.9.2 (PIN Security); The Originator must post the notice in a prominent
and conspicuous location and a copy of such
(e) Subsection 2.5.9.3 (ODFI Warrants that the notice, or language that is substantially similar,
Originator has Satisfied Applicable PIN must be provided to the Receiver at the time of the
Requirements). transaction.

SUBSECTION 2.5.10  Specific Provisions for POP The requirements of Subsection 2.3.2.3(c) (Form
Entries (Point-of-Purchase Entry) of Authorization) concerning revocation of
authorization do not apply to a POP Entry.
SUBSECTION 2.5.10.1  General Rule for
POP Entries For a POP Entry to a non-Consumer Account,
A POP Entry is a Single Entry debit originated Subsection 2.3.3.1 (Agreement to be Bound by the
based on an Eligible Source Document provided Rules) does not apply.
to an Originator by a Receiver at the point-of-
purchase or manned bill payment location for SUBSECTION 2.5.10.3  Eligible Source
conversion at the point-of-purchase or manned bill Document Required
payment location. A POP Entry may be used only An Originator must use an Eligible Source
for an in-person transaction for which there is no Document provided by the Receiver at the point-
standing authorization with the Originator for the of-purchase or a manned bill payment location as
origination of Entries to the Receiver’s account. An the source document for the Receiver’s routing
ODFI must perform, or ensure that its Originator number, account number, and Check Serial
or Third-Party Sender performs, the requirements Number for a POP Entry. For purposes of POP
of Subsection 2.5.10.2 (Authorization of POP Entries, the Eligible Source Document need not be
Entries by Notification and Written Agreement), completed or signed by the Receiver.
Subsection 2.5.10.3 (Eligible Source Document
Required), Subsection 2.5.10.4 (Capture of Banking SUBSECTION 2.5.10.4  Capture of Banking
Information; Voiding of Source Document), and Information; Voiding of Source Document
Subsection 2.5.10.5 (Originator Must Provide (a) An Originator must initially use a reading
Receipts for POP Entries) below before permitting device to capture the Receiver’s routing
the Originator or Third-Party Sender to initiate a number, account number, and Check
POP Entry. Serial Number from the MICR line of the
Receiver’s Eligible Source Document. Such
SUBSECTION 2.5.10.2  Authorization of POP Entries information may not be key-entered by
by Notification and Written Agreement
the Originator. An Originator may key-
An Originator may satisfy the requirement for enter such information only to correct
authorization of a POP Entry by providing the errors resulting from MICR misreads or
Receiver a notice meeting the requirements of this processing rejects.
subsection and obtaining a written authorization
from the Receiver. The Originator must provide a (b) An Originator must void the Eligible Source
conspicuous notice to the Receiver that includes the Document at the time of the transaction
following, or substantially similar, language prior and return it to the Receiver.
to the receipt of each Eligible Source Document
that is used to initiate each POP Entry: SUBSECTION 2.5.10.5   Originator Must Provide
Receipts for POP Entries
“When you provide a check as (a) 
An Originator must provide the Receiver
payment, you authorize us either to use a receipt containing the following
information from your check to make a information with respect to each POP
one-time electronic fund transfer from Entry to the Receiver’s account:

2 0 1 3 O P E R AT I N G R U L E S OR15
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

(i) Originator name (merchant); Entry warrants to each RDFI and ACH Operator
that:
(ii) company (merchant)/third-party
service provider telephone number; (a) Return of Voided Source Document to
Receiver. The Originator voided the Eligible
(iii) date of transaction; Source Document used to initiate such POP
Entry and returned it to the Receiver at the
(iv) transaction amount; time of the transaction.

(v) 
Check Serial Number of the Eligible (b) Source Document Not Used for Prior POP
Source Document; Entry. The Eligible Source Document
used to initiate the POP Entry has not
(vi) 
merchant number (or other unique been provided by the Receiver for use in
number that identifies the location of initiating any prior POP Entry.
the transaction);
SUBSECTION 2.5.11  Specific Provisions for POS
(vii) terminal city, as that term is defined in Entries (Point-of-Sale Entry)
Regulation E; and
SUBSECTION 2.5.11.1  General Rule for POS
(viii) terminal state, as that term is defined Entries
in Regulation E. A POS Entry is a debit Entry initiated at an
“electronic terminal,” as that term is defined
(b) 
The National Association strongly in Regulation E, to a Consumer Account of the
recommends, but these Rules do not Receiver to pay an obligation incurred in a point-
require, that the Originator also provide of-sale transaction, or to effect a point-of-sale
the following information on the receipt terminal cash withdrawal.
provided to the Receiver:
SUBSECTION 2.5.11.2  PIN Security
(i) merchant address; An ODFI and any Originator and Third-Party
Sender must comply with the American National
(ii) merchant identification number; Standards Institute’s (ANSI) Accredited Standards
Committee (ASC) X9.8 concerning PIN Management
(iii) Receiver’s financial institution routing and Security with respect to the handling of any
number; personal identification number (PIN) in connection
with the authorization of a POS Entry.
(iv) Receiver’s truncated account number;
SUBSECTION 2.5.11.3  ODFI Warrants that the
(v) Receiver’s truncated identification
Originator has Satisfied Applicable PIN Requirements
number; and
If a personal identification number (PIN) is required
(vi) transaction reference number. in connection with the authorization for an POS
Entry, an ODFI warrants that the Originator has
(c) The Originator must not place the Receiver’s complied with the American National Standards
complete account number or complete Institute’s (ANSI) Accredited Standards Committee
identification number on the receipt. (ASC) X9.8 concerning PIN Management and
Security. This provision does not apply if a card
SUBSECTION 2.5.10.6  Additional ODFI Warranties issued by the ODFI or Originator of the Entry
for POP Entries is used in connection with the authorization for
these Entries.
In addition to the other warranties contained
within these Rules, an ODFI originating a POP

OR16 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.5.12  General Rule for PPD Receiver a notice meeting the requirements of this
Entries (Prearranged Payment and Deposit Entry) subsection and obtaining the item to which the
A PPD Entry is a credit Entry or debit Entry RCK Entry relates. The Originator must provide a
originated by an Organization to a Consumer conspicuous notice to the Receiver that has clear
Account of a Receiver based on a standing or a and readily understandable terms for initiating
Single Entry authorization from the Receiver. RCK Entries in advance of receiving the item to
An authorization for a debit PPD Entry must be which the RCK Entry relates.
in writing, and signed or similarly authenticated
by the Receiver, as provided in Section 2.3 The requirements of Subsection 2.3.2.3(c) (Form
(Authorization and Notice of Entries). of Authorization) concerning revocation of
authorization do not apply to an RCK Entry.
SUBSECTION 2.5.13  Specific Provisions for RCK
Entries (Re-presented Check Entry) SUBSECTION 2.5.13.3  RCK Eligible Items
An Originator may initiate an RCK Entry only in
SUBSECTION 2.5.13.1  General Rule for RCK relation to an item that:
Entries
An RCK Entry is a debit Entry used to collect the (a) is an item within the meaning of Revised
amount of a Check returned for insufficient or Article 4 of the Uniform Commercial Code
uncollected funds. If an eligible item as described (1990 Official Text);
in Subsection 2.5.13.3 (RCK Eligible Items) is
returned by a Participating DFI, an ODFI may (b) 
is a negotiable demand draft drawn on
initiate an RCK Entry. As provided in Section or payable through or at a Participating
8.68 (“RCK Entry”), an RCK Entry is deemed to DFI, other than a Federal Reserve Bank or
be a presentment notice for purposes of Revised Federal Home Loan Bank;
Article 4 of the Uniform Commercial Code (1990
Official Text), receipt of the RCK Entry constitutes (c) contains a pre-printed serial number;
presentment of the item pursuant to Article
4-110, and return of the RCK Entry constitutes (d) is in an amount less than $2,500;
notice of dishonor or non-payment pursuant
to Article 4-301. The provisions of these Rules (e) indicates on the face of the document that
that are applicable to RCK Entries are intended the item was returned due to “Not Sufficient
to constitute a modification of Regulation CC by Funds,” “NSF,” “Uncollected Funds,” or
agreement as provided at 12 C.F.R. Part 229.37 of comparable language;
Federal Reserve Regulation CC.
(f) is dated 180 days or less from the date the
An ODFI must perform, or ensure that its Originator RCK Entry is Transmitted to the RDFI (i.e.,
or Third-Party Sender performs, the requirements of the item to which the RCK Entry relates is
Subsection 2.5.13.2 (Authorization of RCK Entries not stale-dated);
by Notification), Subsection 2.5.13.3 (RCK Eligible
Items), Subsection 2.5.13.4 (RCK Ineligible Items), (g) is drawn on a Consumer Account; and
Subsection 2.5.13.5 (Retention and Provision of a
Copy of Item), Subsection 2.5.13.6 (Agreement of (h) has been previously presented:
Originator That Restrictive Endorsement is Void or
Ineffective), and Subsection 2.5.13.7 (Reinitiation (i) no more than two times through the
of Returned RCK Entries) below before permitting check collection system (as a Check,
the Originator or Third-Party Sender to initiate an substitute check, or image), if the
RCK Entry. Entry is an initial RCK Entry; or

SUBSECTION 2.5.13.2  Authorization of RCK Entries (ii) no more than one time through the
by Notification check collection system (as a Check,
An Originator may satisfy the requirement for substitute check, or image), and
authorization of an RCK Entry by providing the no more than one time as an RCK

2 0 1 3 O P E R AT I N G R U L E S OR17
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Entry, if the Entry is a reinitiated RCK copy of the item as paid on its face. The
Entry in accordance with Subsection ODFI must provide the copy to the RDFI
2.5.13.7 (Reinitiation of Returned RCK within ten Banking Days of receipt of the
Entries). RDFI’s request for the copy.

SUBSECTION 2.5.13.4  RCK Ineligible Items SUBSECTION 2.5.13.6  Agreement of Originator

Examples of items an Originator may not use to That Restrictive Endorsement is Void or Ineffective
initiate an RCK Entry include the following: An ODFI must obtain the agreement of the
Originator that any restrictive endorsement made
(a) 
noncash items (as defined in Section by the Originator or its agent on the item to which
229.2(u) of Regulation CC); the RCK Entry relates is void or ineffective upon
initiation of the RCK Entry.
(b) drafts drawn on the Treasury of the United
States, a Federal Reserve Bank, or a Federal SUBSECTION 2.5.13.7  Reinitiation of Returned
Home Loan Bank; RCK Entries
An Originator or ODFI may reinitiate any RCK
(c) drafts drawn on a state or local government Entry that was previously returned if:
that are not payable through or at a
Participating DFI; (a) 
the RCK Entry has been returned for
insufficient or uncollected funds; and
(d) United States Postal Service money orders;
(b) 
the item to which the RCK Entry relates
(e) 
items payable in a medium other than has been presented no more than one time
United States currency; through the check collection system (as a
Check, substitute check, or image) and no
(f) items payable to a person other than the more than one time as an RCK Entry.
Originator; and
SUBSECTION 2.5.13.8  Additional ODFI Warranties
(g) 
drafts that do not contain the original for RCK Entries
signature of the Receiver, including In addition to the other warranties contained
remotely created checks, as defined by within these Rules, an ODFI originating an RCK
Regulation CC. Entry warrants to each RDFI and ACH Operator
that:
SUBSECTION 2.5.13.5  Retention and Provision of a
Copy of Item (a) Good Title to the Returned Item. The ODFI
(a) Retention of Copy of Item. An Originator has good title or is entitled to enforce the
must retain a copy of the front and back of item to which the RCK Entry relates or is
the item to which the RCK Entry relates for authorized to obtain payment or acceptance
seven years from the Settlement Date of the on behalf of one who has good title or is
RCK Entry. entitled to enforce the item.

(b) Provision of Copy of Item. At the request of (b) Signatures Are Genuine. All signatures on
the ODFI, the Originator must provide the the item to which the RCK Entry relates are
copy of the front and back of the item to the authentic and authorized.
ODFI for its use or for the use of an RDFI
requesting the information in accordance (c) Item Not Altered. The item to which the
with Subsection 3.1.5 (RDFI Obligation RCK Entry relates has not been altered.
to Provide Information About Entries). If
the item has been finally paid prior to the No Defenses. The item to which the RCK
(d) 
Originator’s provision of a copy of the item Entry relates is not subject to a defense or
to the ODFI, the Originator must mark the claim in recoupment of any party that can
be asserted against the ODFI.

OR18 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

No Knowledge of Insolvency. The ODFI

(e)  SUBSECTION 2.5.14.2  ODFI is Responsible for
has no knowledge of any insolvency PIN Security
proceeding commenced with respect to An ODFI and any Originator and Third-Party
the maker or acceptor, or, in the case of an Sender must comply with the American National
unaccepted draft, the drawer of the item to Standards Institute’s (ANSI) Accredited Standards
which the RCK Entry relates. Committee (ASC) X9.8 concerning PIN Management
and Security with respect to the handling of any
(f) E
 ntry Accurately Reflects Item. The item personal identification number (PIN) in connection
to which the RCK Entry relates is drawn with the authorization of an SHR Entry.
on, payable through, or payable at the
RDFI, and the amount of the item, the item SUBSECTION 2.5.14.3  ODFI Warrants that the
number, and the account number contained Originator has Satisfied Applicable PIN Requirements
on the item have been accurately reflected If a personal identification number (PIN) is required
in the RCK Entry. in connection with the authorization for an SHR
Entry, an ODFI warrants that the Originator has
Item Will Not Be Presented. Neither the
(g)  complied with the American National Standards
item to which an RCK Entry relates, nor Institute’s (ANSI) Accredited Standards Committee
any copy of such item, will be presented to (ASC) X9.8 concerning PIN Management and
the RDFI subsequent to the origination of Security. This provision does not apply if a card
the RCK Entry unless the related RCK Entry issued by the ODFI or Originator of the Entry
has been returned by the RDFI. is used in connection with the authorization for
these Entries.
(h) 
Encoding Is Correct. The information
encoded in magnetic ink on the item to SUBSECTION 2.5.14.4  Rules Exceptions for
which the RCK Entry relates after issuance SHR Entries
of the item is correct.
The requirements of Subsection 2.3.2.5 (Retention
and Provision of the Record of Authorization) do
Restrictive Endorsement is Void or
(i) 
not apply to SHR Entries.
Ineffective. The Originator has agreed that
any restrictive endorsement made by the
The following sections do not apply to SHR Entries
Originator or its agent on the item to which
if a card issued by the ODFI or Originator of the
the RCK Entry relates is void or ineffective
Entry is used in connection with the authorization
upon initiation of the RCK Entry.
of the SHR Entries:

SUBSECTION 2.5.14  Specific Provisions for SHR (a) Subsection 2.5.9.2 (PIN Security); and
Entries (Shared Network Entry)
(b) 
Subsection 2.5.14.3 (ODFI Warrants that
SUBSECTION 2.5.14.1  General Rule for SHR
Entries the Originator has Satisfied Applicable PIN
Requirements).
An SHR Entry is a debit Entry initiated at an
“electronic terminal,” as that term is defined
SUBSECTION 2.5.15  Specific Provisions for TEL
in Regulation E, to a Consumer Account of the
Entries (Telephone-Initiated Entry)
Receiver to pay an obligation incurred in a
point-of-sale transaction, or to effect a point-of- SUBSECTION 2.5.15.1  General Rule for TEL Entries
sale terminal cash withdrawal. SHR Entries are
A TEL Entry is a debit Entry originated based on an
initiated in a shared network where the ODFI and
oral authorization provided to the Originator by a
RDFI have an agreement in addition to these Rules
Receiver via the telephone. A TEL Entry may only
to process such Entries.
be used when there is an Existing Relationship
between the Originator and the Receiver, or, when

2 0 1 3 O P E R AT I N G R U L E S OR19
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

there is not an Existing Relationship between the Receiver with written notice confirming the oral
Originator and the Receiver, when the Receiver authorization prior to the Settlement Date of the
initiates the telephone call. An ODFI must perform, Entry.
or ensure that its Originator or Third-Party Sender
performs, the requirements of Subsection 2.5.15.2 The following minimum information must be
(Authorization of TEL Entries) and Subsection included as part of the authorization of a recurring
2.5.15.3 (Retention of the Record of Authorization TEL Entry:
for TEL Entries) below before permitting the
Originator or Third-Party Sender to initiate a TEL (h) the amount of the recurring transactions, or
Entry. a reference to the method of determining
the amounts of recurring transactions;
SUBSECTION 2.5.15.2  Authorization of TEL Entries
An Originator must satisfy the requirement for (i) 
the timing (including the start date),
authorization of a TEL Entry by obtaining oral number, and/or frequency of the electronic
authorization from the Receiver to initiate a debit fund transfers, or other similar reference,
Entry to a Consumer Account of the Receiver. to the Consumer’s account;
The authorization must be readily identifiable as
an authorization and must have clear and readily (j) the Receiver’s name or identity;
understandable terms.
(k) the account to be debited;
The following minimum information must be
included as part of the authorization of a Single (l) a telephone number for Receiver inquiries
Entry TEL Entry: that is answered during normal business
hours; and
(a) the date on or after which the ACH debit to
(m) the date of the Receiver’s oral authorization.
the Receiver’s account will occur;
For an authorization relating to recurring TEL
(b) the amount of the transaction or a reference
Entries, the Originator must comply with the
to the method of determining the amount
requirements of Regulation E for the authorization
of the transaction;
of preauthorized transfers, including the
(c) the Receiver’s name or identity; requirement to send a copy of the authorization
to the Receiver.
(d) the account to be debited;
SUBSECTION 2.5.15.3  Retention of the Record of
(e) a telephone number for Receiver inquiries Authorization for TEL Entries
that is answered during normal business An Originator must retain the original or a copy
hours; of the written notice or the original or a duplicate
audio recording of the oral authorization for two
(f) the date of the Receiver’s oral authorization; years from the date of the authorization of a
and Single Entry TEL Entry. For recurring TEL Entries,
an Originator must retain for two years from the
(g) 
a statement by the Originator that the termination or revocation of the authorization (i)
authorization obtained from the Receiver the original or a duplicate audio recording of the
is for a Single-Entry ACH debit, a one-time oral authorization, and (ii) evidence that a copy of
electronic funds transfer, or other similar the authorization was provided to the Receiver in
reference. compliance with Regulation E.

For an authorization relating to a Single Entry TEL SUBSECTION 2.5.15.4  Additional ODFI Warranties
Entry, the Originator must either make an audio for TEL Entries
recording of the oral authorization, or provide the In addition to the other warranties contained
within these Rules, an ODFI originating a TEL

OR20 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Entry warrants to each RDFI and ACH Operator directly or indirectly from the debiting of the Entry
that: to the deposit account identified in the Entry.

(a) V
 erification of Receiver’s Identity. The SUBSECTION 2.5.16.4  Rules Exceptions for TRC
Originator has established and implemented Entries and TRX Entries
commercially reasonable procedures to The following sections do not apply to TRC and
verify the identity of the Receiver. TRX Entries:

(b) V
 erification of Routing Numbers. The (a) Section 1.7 (Choice of Law);
Originator has established and implemented
(b) Section 2.2 (Prerequisites to Origination);
commercially reasonable procedures to
verify that routing number used in the TEL (c) 
Section 2.3 (Authorization and Notice of
Entry is valid. Entries);
(d) 
Section 2.4 (General Warranties and
SUBSECTION 2.5.15.5 Rules Exceptions for TEL Liabilities of ODFIs);
Entries
The requirement that an Electronic authorization (e) Section 2.6 (Prenotifications);
must be visually displayed in a manner that (f) Section 2.9 (Reversing Entries);
enables the consumer to read the communication,
(g) 
Section 2.10 (Reclamation Entries and
as required by Subsection 2.3.2.4 (Electronic
Written Demands for Payment);
Authorizations), does not apply to TEL Entries.
(h) Subsection 2.12.4 (Reinitiation of Returned
SUBSECTION 2.5.16  Specific Provisions for Entries);
TRC and TRX Entries (Check Truncation Entry) (i) Section 8.12 (“Banking Day”);
SUBSECTION 2.5.16.1  General Rule for TRC and (j) Section 8.38 (“File”);
TRX Entries (k) Section 8.63 (“Person”);
A TRC or TRX Entry is a debit Entry initiated under
(l) Appendix Four (Return Entries);
a Check Truncation Program. This Subsection
2.5.16 applies to all TRC and TRX Entries initiated (m) Appendix Five (Notification of Change);
under the rules of a Check Truncation Program, (n) Appendix Seven (Compensation Rules);
unless otherwise provided for in the rules of the
Check Truncation Program. A TRC Entry and TRX (o) Appendix Eight (Rule Compliance Audit
Entry also shall constitute a “demand for payment” Requirements);
under Articles 3 and 4 of the UCC. (p) Appendix Nine (Arbitration Procedures).

SUBSECTION 2.5.16.2  TRC Entries and TRX SUBSECTION 2.5.16.5  Conflicts Between Rules and
Entries are Permitted Only to Eligible Participants Check Truncation Program Rules
An ODFI may Transmit a TRC Entry or TRX Entry If there is a conflict between this Subsection 2.5.16
to an RDFI only if the ODFI and RDFI each and the rules of a Check Truncation Program, the
are participants in the same Check Truncation Check Truncation Program’s rules govern.
Program.
SUBSECTION 2.5.17  Specific Provisions for WEB
SUBSECTION 2.5.16.3  Indemnification by ODFI for Entries (Internet-Initiated/Mobile Entry)
Misrouted TRC Entries and TRX Entries
An ODFI that Transmits a TRC Entry or TRX SUBSECTION 2.5.17.1  General Rule for
Entry to an RDFI not participating in the same WEB Entries
Check Truncation Program as the ODFI shall A WEB Entry is a debit Entry to a Consumer
indemnify the RDFI from and against any and all Account originated based on (1) an authorization
claims, demands, losses, liabilities, and expenses, that is communicated, other than by an oral
including attorneys’ fees and costs, resulting communication, from the Receiver to the Originator

2 0 1 3 O P E R AT I N G R U L E S OR21
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

via the Internet or a Wireless Network; or (2) any (a) Fraud Detection Systems. The Originator
form of authorization if the Receiver’s instruction has established and implemented a
for the initiation of the individual debit Entry is commercially reasonable fraudulent
designed by the Originator to be communicated, transaction detection system to screen the
other than by an oral communication, to the WEB Entry.
Originator via a Wireless Network. An ODFI
must perform, or ensure that its Originator or (b) 
Verification of Receiver’s Identity.
Third-Party Sender performs, the requirements The Originator has established and
of Subsection 2.5.17.2 (Authorization of WEB implemented commercially reasonable
Entries) and Subsection 2.5.17.3 (WEB Annual methods of authentication to verify the
Audit) below before permitting an Originator or identity of the Receiver of the WEB Entry.
Third-Party Sender to initiate a WEB Entry.
(c) Verification of Routing Numbers. The
SUBSECTION 2.5.17.2  Authorization of Originator has established and implemented
WEB Entries commercially reasonable procedures to
An Originator must satisfy the requirement for verify that the routing number used in the
authorization of a WEB Entry to a Consumer WEB Entry is valid.
Account of the Receiver by (1) obtaining written
authorization from the Receiver via the Internet or SUBSECTION 2.5.18  Specific Provisions for
a Wireless Network; or (2) obtaining the Receiver’s XCK Entries (Destroyed Check Entry)
authorization in any manner permissible under
SUBSECTION 2.5.18.1  General Rule for
Subsection 2.3.2 (Authorizations and Notices with
XCK Entries
Respect to Consumer Accounts), and the Receiver’s
instruction for the initiation of the individual debit An ODFI may originate an XCK entry for an eligible
Entry is communicated, other than by an oral item as described in Subsection 2.5.18.2 (XCK
communication, via a Wireless Network. Eligible Items). Notwithstanding Section 8.33
(“Entry”), an XCK Entry shall not be deemed to be
an item under Article 4 of the Uniform Commercial
SUBSECTION 2.5.17.3  WEB Annual Audit
Code, and neither Transmittal to nor receipt by an
An Originator of the WEB Entry must conduct,
RDFI of an XCK Entry shall constitute presentment
or have conducted on its behalf, annual audits to
of the original item.
ensure that the financial information it obtains
from Receivers is protected by security practices
SUBSECTION 2.5.18.2  XCK Eligible Items
and procedures that include, at a minimum,
adequate levels of: An ODFI may initiate an XCK Entry only in relation
to an item that:
(a) 
physical security to protect against theft,
tampering, or damage; (a) is an item within the meaning of Article 4
of the Uniform Commercial Code;
(b) 
personnel and access controls to protect
against unauthorized access and use; and (b) 
is a negotiable demand draft drawn on
or payable through or at an office of a
(c) network security to ensure secure capture, Participating DFI, other than a Federal
storage, and distribution. Reserve Bank or Federal Home Loan Bank;

(c) is in an amount less than $2,500; and

SUBSECTION 2.5.17.4  Additional ODFI Warranties
for WEB Entries
(d) either (1) is contained in a cash letter that
In addition to the other warranties contained
is lost, destroyed, or otherwise unavailable
within these Rules, an ODFI originating a WEB
while in transit for presentment to a paying
Entry warrants to each RDFI and ACH Operator
bank, and cannot be obtained; or (2) (i)
that:

OR22 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

is missing part of the MICR line but can SUBSECTION 2.5.18.5  Additional ODFI Warranties
be sufficiently repaired to create an ACH for XCK Entries
Entry; (ii) is an image of an item that cannot In addition to the other warranties contained
be processed through the applicable image within these Rules, an ODFI originating an XCK
exchange, but has sufficient information to Entry warrants to each RDFI and ACH Operator
create an Entry; or (iii) is, in whole or in that:
part, unreadable, obscured, or mutilated in
a manner that prevents automated check (a) Good Title to the Check. The ODFI has
processing or creation of an image that can good title to or is entitled to enforce the
be used to produce a “substitute check” item to which the XCK Entry relates or is
that is the legal equivalent of the original authorized to obtain payment or acceptance
check under the Check Clearing for the on behalf of one who has good title or is
21st Century Act, Pub. L. 108-100, but has entitled to enforce the item.
sufficient information to create an Entry.
(b) Signatures are Genuine. All signatures on
SUBSECTION 2.5.18.3  XCK Ineligible Items the item to which the XCK Entry relates are
Examples of items an ODFI may not use originate authentic and authorized.
an XCK Entry include:
No Alterations. The item to which the XCK
(c) 
(a) 
noncash items (as defined in Section Entry relates has not been altered.
229.2(u) of Regulation CC);
(d) No Defenses. The item to which the XCK
(b) drafts drawn on the Treasury of the United Entry relates is not subject to a defense or
States, a Federal Reserve Bank, or a Federal claim in recoupment of any party that can
Home Loan Bank; be asserted against the ODFI.

(c) drafts drawn on a state or local government (e) No Knowledge of Insolvency. The ODFI
that are not payable through or at a has no knowledge of any insolvency
Participating DFI; proceeding commenced with respect to
the maker or acceptor or, in the case of an
(d) United States Postal Service money orders; unaccepted draft, the drawer of the item to
which the XCK Entry relates.
(e) 
items payable in a medium other than
United States currency; and (f) Item Drawn on RDFI. The item to which
the XCK Entry relates is drawn on, payable
(f) returned items. through, or payable at the RDFI.

SUBSECTION 2.5.18.4  Provision of Copy of Item (g) XCK Entry Accurately Reflects Item. The
to RDFI or Other DFI amount of the item to which the XCK Entry
An ODFI must provide a copy of the item to which relates, the item number, and account
the XCK Entry relates to the RDFI, and to the first number contained on such item have been
DFI to which such item was transferred if different accurately reflected in the XCK Entry.
from the ODFI, within thirty days of receiving a
written request from the RDFI, or such other DFI, (h) Item Has Not Been Presented. Neither the
respectively, provided that such request is received item to which the XCK Entry relates, nor
within six years of the date on which the ODFI any copy (including any image) of such
initiated the XCK Entry. item, has been presented and will not be
presented to the RDFI.

2 0 1 3 O P E R AT I N G R U L E S OR23
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

(i) Authority and Eligibility. The ODFI has SECTION 2.7  Recall by ODFI or
all necessary authority to initiate the XCK Originator
Entry, and the item to which the XCK Entry
Neither an Originator nor an ODFI has the right
relates satisfies the eligibility requirements
to recall an Entry or File, to require the return of
of Subsection 2.5.18.2 (XCK Eligible Items).
or adjustment to an Entry, or to stop the payment
or posting of an Entry, once the Entry or File has
SUBSECTION 2.5.18.6  Rules Exceptions for
been received by the Originating ACH Operator,
XCK Entries
except as allowed by Section 2.8 (Reversing Files),
The following subsections do not apply to XCK Section 2.9 (Reversing Entries), and Section 2.10
Entries: (Reclamation Entries and Written Demands for
Payment).
(a) 
Subsection 2.2.1 (ODFI Agreement With
Originator, Third Party Sender or Sending
Point);
SECTION 2.8  Reversing Files
SUBSECTION 2.8.1  General Rule for Reversing
(b) 
Section 2.3 (Authorization and Notice of Files­
Entries); and
An Originator or an ODFI may initiate a Reversing
File to reverse all Entries of an Erroneous File.
(c) Subsection 2.4.1.1 (The Entry is Authorized
by the Originator and Receiver).
SUBSECTION 2.8.2  Obligation to Initiate
SECTION 2.6 Prenotifications Correcting Files Corresponding to Reversing
Files
SUBSECTION 2.6.1  General Rule for An Originator or ODFI initiating a Reversing File
Prenotifications to correct an Erroneous File must concurrently
Prior to the initiation of the first credit or debit initiate a Correcting File corresponding to the
Entry to a Receiver’s account with an RDFI, an Erroneous File, unless the Erroneous File was a
Originator may originate a Prenotification Entry to duplicate.
the RDFI.
SUBSECTION 2.8.3  Time Limitations on Initiation
SUBSECTION 2.6.2  Six Banking Days’ Delay; of Reversing Files
Return Entries and Notifications of Change An Originator or the ODFI must Transmit
An Originator that has originated a Prenotification each Reversing File and, when appropriate, a
may not originate Entries to a Receiver’s account corresponding Correcting File, to the ACH Operator
sooner than six Banking Days following the within five Banking Days after the Settlement Date
Settlement Date of the Prenotification. If the ODFI of the Erroneous File. The Originator or ODFI must
receives a Return Entry within the six Banking Day Transmit the Reversing File and any corresponding
period indicating that the RDFI will not accept Correcting File to the ACH Operator within twenty-
Entries, then the Originator must not originate four hours of the discovery of the Erroneous File.
such Entries. If the ODFI receives a Notification
of Change within the six Banking Day period SUBSECTION 2.8.4  Indemnification for
indicating that the RDFI requires the requested Reversing Files
changes to be made prior to the initiation of An ODFI that initiates a Reversing File or Correcting
such Entries, the Originator must not initiate such File shall indemnify each Participating DFI and
Entries unless the requested changes have been ACH Operator from and against any and all
made. claims, demands, losses, liabilities, and expenses,
including attorneys’ fees and costs, that result
directly or indirectly from the debiting or crediting
of any Entry in the Reversing File or corresponding
Correcting File to the Receiver’s account.

OR24 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.8.5  Rules Exceptions for (iii) the credit PPD Entry was Transmitted
Reversing File by the Originator prior to the delivery
The following sections and subsections do not of the Check to the Receiver.
apply to a Reversing File complying with the
requirements of this Section 2.8: The Originator must make a reasonable attempt
to notify the Receiver of the Reversing Entry
(a) Section 2.2 (Prerequisites to Origination); and the reason for the Reversing Entry no later
and than the Settlement Date of the Reversing Entry.
For a credit PPD Entry satisfying the criteria of
(b) 
Section 2.4 (General Warranties and Subsection 2.9.1(d) above, the Originator must
Liabilities of Originating Depository notify the Receiver of the Reversing Entry at the
Financial Institutions). time the Check is delivered to the Receiver.

SECTION 2.9  Reversing Entries SUBSECTION 2.9.2  Indemnification for

Reversing Entries
SUBSECTION 2.9.1  General Rule for Reversing An ODFI that initiates a Reversing Entry shall
Entries indemnify each RDFI and ACH Operator from
An Originator may initiate a Reversing Entry to and against any and all claims, demands, losses,
correct an Erroneous Entry previously initiated to liabilities, and expenses, including attorneys’ fees
a Receiver’s account. The Reversing Entry must be and costs, that result directly or indirectly from the
Transmitted to the ACH Operator in such time as debiting or crediting of the Reversing Entry to the
to be Transmitted or made available to the RDFI Receiver’s account.
within five Banking Days following the Settlement
Date of the Erroneous Entry. SUBSECTION 2.9.3  Rules Exceptions for
Reversing Entries
For this Section 2.9 and Subsection 2.12.2 (ODFI The following subsections do not apply to
Request for Return) only, an Erroneous Entry is Reversing Entries complying with the requirements
defined as an Entry that: of this Section 2.9:

(a) 
is a duplicate of an Entry previously (a) 
Subsection 2.3 (Authorization and Notice
initiated by the Originator or ODFI; of Entries); and

(b) 
orders payment to or from a Receiver (b) Subsection 2.4.1.1 (The Entry is Authorized
different than the Receiver intended to be by the Originator and Receiver).
credited or debited by the Originator;
SECTION 2.10  Reclamation Entries and
(c) orders payment in a dollar amount different
Written Demands for Payment
than was intended by the Originator; or
SUBSECTION 2.10.1  Prerequisites for a
(d) is a credit PPD Entry satisfying each of the Reclamation Entry or Written Demand for
following criteria: Payment
An Originator or ODFI may initiate a Reclamation
(i) 
the credit PPD Entry is for funds Entry or written demand for payment with
related to a Receiver’s employment; respect to a previously Transmitted credit Entry
to a Receiver’s account under the following
(ii) 
the value of the credit PPD Entry circumstances:
is fully included in the amount of a
Check delivered to the same Receiver (a) The Receiver has died and the Receiver’s
at or prior to the Receiver’s separation right to receive one or more pension,
from employment; and annuity, or other benefit payments has

2 0 1 3 O P E R AT I N G R U L E S OR25
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

terminated before the receipt by the SUBSECTION 2.10.6  Alteration of Reclamation

RDFI of one or more credit Entries to the Provisions by Agreement – Originator
Receiver’s account; and Notwithstanding any other provision of these
Rules, the liability provisions contained within
(b) Neither the Receiver’s estate nor any other this Section 2.10 and Subsection 3.6.2 (Liability
holder of the account is entitled to the of RDFI for Reclamation Entries and Written
payments. Demands for Payment) may be altered, amended,
or superseded by a written agreement between the
SUBSECTION 2.10.2  Amount of a Reclamation Originator and RDFI only if the agreement clearly
Entry or Written Demand for Payment and conspicuously states on its face that it is a
An Originator or ODFI must not initiate a master agreement, that both the Originator and
Reclamation Entry or written demand for payment RDFI consider it to be a master agreement, and
in an amount that exceeds the amount of any that it is applicable to all payments subject to this
payment to which the Receiver was not entitled. Section 2.10 and Subsection 3.6.2 Transmitted by
the Originator to the RDFI for the benefit of all
SUBSECTION 2.10.3  Content of a Reclamation Receivers having accounts at the RDFI.
Entry or Written Demand for Payment
An Originator or ODFI must identify in each SUBSECTION 2.10.7  Specific Warranties for
Reclamation Entry or written demand for payment Reclamation Entries
the name of the Receiver, the account at the RDFI In addition to the other warranties contained within
credited on the Receiver’s behalf, and the exact these Rules, an ODFI initiating a Reclamation Entry
amount and approximate date of initiation for warrants the following to each RDFI and ACH
each Entry involved. Operator in connection with such Reclamation
Entry at the time of Transmission:
SUBSECTION 2.10.4  Timing Requirements for
Reclamation Entries and Written Demands (a) all information is accurate and applies to
for Payment the Receiver and account identified in the
An Originator or ODFI must originate a Reclamation Reclamation Entry or written demand for
Entry or written demand for payment within five payment;
Banking Days after the Originator receives notice
of the death of the Receiver. If a Reclamation Entry (b) 
the Reclamation Entry was originated,
is returned by the RDFI, the Originator may make a or written demand for payment was
written demand for payment within fifteen Banking sent, within the time limits set forth in
Days after it receives the returned Reclamation Subsection 2.10.4 (Timing Requirements for
Entry. For this subsection, notice received by the Reclamation Entries and Written Demands
Originator is considered to be effective from the for Payment), satisfies the conditions set
time specified in Section 1-201(27) of the Uniform forth in Subsection 2.10.1 (Prerequisites for
Commercial Code (1978 Official Text). a Reclamation Entry or Written Demand for
Payment), and is authorized by applicable
SUBSECTION 2.10.5  Superiority of United States Legal Requirements; and
Government Claims
A claim or demand by an Originator (or ODFI on (c) the RDFI’s right and obligation to pay the
the Originator’s behalf) pursuant to this Section Reclamation Entry are not limited to the
2.10 will be subordinate to claims or potential number of parties having an interest in the
claims of the United States Government under 31 account.
C.F.R. Part 210. The Originator must reimburse
the RDFI for any payments made to the Originator SUBSECTION 2.10.8  Rules Exceptions for
pursuant to this Section 2.10 that are subject to a Reclamation Entries and Written Demands
for Payment
subsequent claim of the United States Government
under 31 C.F.R. Part 210. The following subsections do not apply to
Reclamation Entries complying with the
requirements of this Section 2.10:

OR26 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

(a) 
Subsection 2.3.2.6 (Notices of Variable SUBSECTION 2.11.2  ODFI Right to Refuse
Debits to Consumer Accounts); Notification of Change Entries
An ODFI may refuse an NOC or corrected NOC for
(b) Subsection 2.4.1.1(b) and (c) (The Entry is all Entries except IAT Entries if:
Authorized by the Originator and Receiver);
(a) 
the NOC or corrected NOC contains
(c) Subsection 2.4.1.5 (Credit Entry Is Timely); incorrect information;

(d) Subsection 2.4.1.6 (Debit Entry Satisfies an (b) the NOC or corrected NOC does not contain
Obligation or Corrects an Error). all information required by Appendix Five
(Notification of Change); or
SECTION 2.11  Notifications of Change
(c) 
the NOC otherwise fails to comply with
SUBSECTION 2.11.1  ODFI and Originator Action Appendix Five (Notification of Change).
on Notification of Change (NOC)
An ODFI must accept a Notification of Change To refuse an NOC or corrected NOC, the ODFI
(also known as “NOC” and “COR Entry”) or a must Transmit a refused NOC complying with
corrected NOC that complies with the requirements Appendix Five (Notification of Change) to its ACH
of Appendix Five (Notification of Change) and is Operator within fifteen days of receipt of the NOC
Transmitted by the RDFI within the time limits or corrected NOC.
established by these Rules, unless otherwise
provided for in this Section 2.11. SECTION 2.12  Return Entries
For each NOC or corrected NOC it receives, an ODFI SUBSECTION 2.12.1  ODFI Acceptance of Timely
must provide the Originator with the following Return Entries and Extended Return Entries
minimum information within two Banking Days of An ODFI must accept Return Entries and Extended
the Settlement Date of the NOC or corrected NOC: Return Entries that comply with these Rules and
that are Transmitted by the RDFI within the time
(a) company name; limits established by these Rules.
(b) company identification;
SUBSECTION 2.12.2  ODFI Request for Return
(c) company Entry description;
An ODFI may, orally or in writing, request an RDFI
(d) effective Entry date; to return an Erroneous Entry initiated by the ODFI.
(e) DFI account number; The RDFI may, but is not obligated to, comply
with this request. For purposes of this subsection,
(f) individual name/receiving company name; an Erroneous Entry has the same meaning as in
(g) individual identification number/ Section 2.9 (Reversing Entries).
identification number;
SUBSECTION 2.12.3  Indemnification by ODFI for
(h) change code;
Requested Returns
(i) original Entry trace number; An ODFI requesting that an RDFI return an
(j) original RDFI identification; and Erroneous Entry indemnifies the RDFI from
and against any and all claims, demands, losses,
(k) corrected data.
liabilities and expenses, including attorneys’ fees
and costs, resulting directly or indirectly from
The Originator must make the changes specified
compliance by the RDFI with such request.
in the NOC or corrected NOC within six Banking
Days of receipt of the NOC information or prior to
initiating another Entry to the Receiver’s account,
whichever is later.

2 0 1 3 O P E R AT I N G R U L E S OR27
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SUBSECTION 2.12.4  Reinitiation of (c) the Return Entry was misrouted;

Returned Entries
An Originator or ODFI may reinitiate any Entry, (d) the Return Entry was a duplicate;
other than an RCK Entry, that was previously
returned if: (e) the Return Entry is coded as the Return of
an Erroneous Entry at the request of the
(a) the Entry was returned for insufficient or ODFI, as permitted by Subsection 2.12.2
uncollected funds; (ODFI Request for Return), but the ODFI
did not make such a request; or
(b) the Entry was returned for stopped payment
and reinitiation has been authorized by the (f) the Return Entry is coded as a permissible
Receiver; or Return Entry, as permitted by Subsection
3.8.3.5 (Late Return Entries for CCD or CTX
(c) the Originator or ODFI has taken corrective Entries with ODFI Agreement), but the
action to remedy the reason for the return. ODFI did not agree to accept the Return
Entry.
The Originator or ODFI must reinitiate the Entry
within one hundred eighty days after the Settlement To dishonor a Return Entry, the ODFI must
Date of the original Entry. An Originator or ODFI Transmit a dishonored Return Entry complying
must not reinitiate an Entry that has been returned with Appendix Four (Return Entries) to its ACH
for insufficient or uncollected funds more than two Operator within five Banking Days after the
times following the return of the original Entry. Settlement Date of the Return Entry.

SUBSECTION 2.12.5  Dishonor of Return Entries SUBSECTION 2.12.5.2  ODFI Must Accept a
Contested Dishonored Return Entry
SUBSECTION 2.12.5.1  Dishonor of Return by ODFI An ODFI must accept a contested dishonored
An ODFI may dishonor a Return Entry, with the Return Entry (i.e., an Entry rejecting the ODFI’s
exception of an IAT Return Entry, if: dishonor of the Return Entry). Any further action
regarding a contested dishonored Return Entry
(a) the RDFI failed to return the Entry within must be pursued outside of the ACH Network.
the time limits established by these Rules;
SUBSECTION 2.12.6  Discretion to Accept
(b) information in one or more of the following Late Returns
fields of the Return Entry is incorrect or An ODFI may agree to accept a late Return Entry
missing: at its discretion.

(i) DFI Account Number

SECTION 2.13  Refusal of
Acknowledgment (ACK and ATX ) Entries
(ii) Original Entry Trace Number
An ODFI may refuse an ACK or ATX Entry if:
(iii) Dollar Amount
(a) the ACK or ATX Entry contains incorrect
(iv) 
Individual Identification Number/ information;
Identification Number
(b) 
the ACK or ATX Entry does not contain
(v) Transaction Code all information required by Appendix Six
(Acknowledgment Entries); or
(vi) Company Identification Number
(c) 
the ACK or ATX Entry otherwise
(vii) Effective Entry Date fails to comply with Appendix Six
(Acknowledgment Entries).

OR28 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

To refuse an ACK or ATX Entry, the ODFI must “If your payment is returned unpaid,
Transmit a refused ACK or ATX Entry, complying you authorize us to make a one-time
with the requirements of Appendix Six, to the electronic fund transfer from your
Originating ACH Operator within fifteen days of account to collect a fee. The fee will be
receipt of the ACK or ATX Entry. determined [by/as follows]: [ ].”

SECTION 2.14  Return Fee Entries SUBSECTION 2.14.3 Formatting Requirements for
Return Fee Entries
SUBSECTION 2.14.1 General Rule for Return Fee
Entries A Return Fee Entry authorized by notice in
accordance with Subsection 2.14.2 (Authorization
An Originator may originate a Return Fee Entry,
of Return Fee Entries) must use the Standard Entry
to the extent permitted by applicable Legal
Class Code “PPD.” A Return Fee Entry authorized
Requirements, in relation to the return of:
in a manner other than by notice must use the
Standard Entry Class Code appropriate to the
(a) a debit Entry to a Consumer Account of a
manner of authorization.
Receiver;
An Originator must submit Return Fee Entries as
(b) 
an ARC, BOC or POP Entry to a non-
a separate batch that contains the words “RETURN
Consumer Account of a Receiver; or
FEE” in the Company Entry Description field of the
Company/Batch Header Record.
(c) an item that was eligible to be converted to
a debit Entry, but was not converted to an
The Company Name field of a Return Fee Entry
Entry.
must contain the same name of the Originator
as identified in the Company Name field of the
For a Return Fee Entry based on the return of
underlying Entry. For a Return Fee Entry based on
an Entry, the Entry must have been returned for
the return of a Check, the Company Name field
insufficient or uncollected funds under the return
must contain the name of the payee of the Check.
codes R01 or R09. For a Return Fee Entry based
on the return of a Check, the returned Check must
SUBSECTION 2.14.4 Other Requirements of
be marked to indicate that it was returned due to
Return Fee Entries
“Not Sufficient Funds, “ NSF,” “Uncollected Funds,”
or comparable language. An Originator may impose only one Return Fee in
relation to an underlying Entry or item that was
SUBSECTION 2.14.2 Authorization of Return Fee returned, whether such Return Fee is collected via
Entries the ACH or otherwise. An Originator may re-initiate
a Return Fee Entry in accordance with Subsection
An Originator may satisfy the requirements for
2.12.4 (Reinitiation of Returned Entries), but an
authorization of the Return Fee Entry by providing
Originator may not originate a Return Fee Entry
notice, at the time that the underlying Entry is
with respect to the return of another Return Fee
authorized or the original item is accepted, of the
Entry.
Return Fee Entry in form, process and content
permissible under Regulation E, regardless of
A Return Fee Entry authorized by notice in
whether the account to be debited is a Consumer
accordance with Subsection 2.14.2 (Authorization
Account or a non-Consumer Account.
of Return Fee Entries) must have a Settlement Date
within 45 days of the Settlement Date of the Return
The notice must include the following, or
Entry of the underlying debit Entry or the return of
substantially similar, language:
the other underlying item.
“If your payment is returned unpaid,
you authorize us to make a one-time SUBSECTION 2.14.5 Additional ODFI Warranty for
Return Fee Entries
electronic fund transfer from your
account to collect a fee of [$ ];” or In addition to the other warranties contained
within these Rules, an ODFI initiating a Return Fee
Entry warrants to each RDFI and ACH Operator

2 0 1 3 O P E R AT I N G R U L E S OR29
ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

that the Originator imposing the Return Fee has SUBSECTION 2.15.3  Performance and Warranty
not and will not impose any other Return Fee in of ODFI Obligations by Third-Party Senders
relation to the underlying Entry or item that was To the extent that a Third-Party Sender performs
returned unpaid. any of the obligations of an ODFI under these
Rules, the Third-Party Sender must perform the
SECTION 2.15  Obligations of Third-Party requirements of these Rules otherwise applicable
Senders, and of ODFIs and Originators to the ODFI, and warrants that it is legally able to
That Use Third-Party Senders do so. The performance by a Third-Party Sender
of any of the obligations of the ODFI under these
An ODFI may originate Entries initiated by a
Rules shall not relieve the ODFI of any of its
Third-Party Sender, subject to compliance with
obligations under these Rules.
these Rules, including Section 2.2 (Prerequisites to
Origination).
SUBSECTION 2.15.4  Payment to ODFI by
Third-Party Senders or Originators
SUBSECTION 2.15.1  Identification of Originators
by Third-Party Senders A Third-Party Sender agrees to make payment to
the ODFI for any credit Entries it originates and
A Third-Party Sender must, upon the ODFI’s
for any debit Entries returned by the RDFI. An
request, provide the ODFI with any information
Originator that utilizes a Third-Party Sender to
the ODFI reasonably deems necessary to identify
authorize an ODFI to Transmit Entries agrees to
each Originator for which the Third-Party Sender
make payment to the ODFI for any credit Entries
Transmits Entries. The information must be
originated and for any such Entries returned by the
provided to the ODFI by the Third-Party Sender
RDFI to the extent that the ODFI does not receive
within two Banking Days of receipt of the ODFI’s
payment from the Third-Party Sender.
request.
SUBSECTION 2.15.5  Performance of Originator
SUBSECTION 2.15.2  Warranty of and
Responsibilities by Third-Party Senders
Indemnification by Third-Party Senders
A Third-Party Sender shall be jointly and severally
A Third-Party Sender initiating one or more Entries
liable with each of its Originators for the retention
through an ODFI to a Receiver’s account warrants
and delivery to the ODFI or RDFI, as required by
to the ODFI that the Originator has agreed to
these Rules, of any Records, documentation or
assume the responsibilities of an Originator under
data regarding records of authorization of Entries,
these Rules. In any case where such Originator
copies of items and copies of Eligible Source
fails to perform its obligations as an Originator
Documents.
under these Rules, the Third-Party Sender
authorizing such Entry indemnifies the ODFI from
and against any and all claims, demands, losses, SECTION 2.16  Authorization by ODFI for
liabilities, and expenses, including attorneys’ fees Release of Designated Data
and costs, that result directly or indirectly from the An ODFI authorizes and instructs each ACH
failure of the Originator to perform its obligations Operator to provide to the National Association
as an Originator under these Rules. Designated Data related to Entries Transmitted to
or by the ODFI, and will hold each ACH Operator
In addition to the other warranties contained harmless against any claim by the ODFI arising
within these Rules, a Third-Party Sender also out of the ACH Operator’s compliance with such
makes to the ODFI each of the warranties set forth instructions.
at Subsection 2.4.1 (General ODFI Warranties),
Subsection 2.5.17.4 (Additional ODFI Warranties
for WEB Entries), and Section 5.2 (Warranties of
Gateway).

OR30 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

SECTION 2.17  ODFI Reporting SUBSECTION 2.17.1.2  ODFIs with No Direct

Requirements to National Association Access Debit Participants
An ODFI that has no Direct Access Debit
SUBSECTION 2.17.1  Direct Access Registration Participants must provide the National Association
with the following information:
SUBSECTION 2.17.1.1  ODFIs with Direct Access
Debit Participants (a) the ODFI’s name;
An ODFI that has one or more Direct Access
Debit Participants must register each relationship (b) the ODFI’s routing number;
with the National Association prior to originating
Entries for the Direct Access Debit Participant(s) (c) 
the name, title, telephone number, and
by providing the following information for each address for a contact person at the ODFI;
Direct Access Debit Participant: and

(a) the ODFI’s name; (d) a statement acknowledging that the ODFI
has no Direct Access Debit Participants.
(b) the ODFI’s routing number(s) provided for
use by a Direct Access Debit Participant; SUBSECTION 2.17.1.3  Direct Access Data
Reporting
(c) 
the name, title, telephone number, and An ODFI that has one or more Direct Access Debit
address for a contact person at the ODFI; Participants must provide the following data to the
National Association on a quarterly basis for each
(d) 
an identification of whether the Direct relationship, in total and by Standard Entry Class
Access Debit Participant is an Originator, Code:
Third-Party Service Provider, or Third-Party
Sender; (a) 
average daily debit Entry origination
volume;
(e) the name, title, address, telephone number,
and taxpayer identification number(s) (b) average daily debit Entry origination dollar
for the Originator, Third-Party Service value;
Provider, or Third-Party Sender; (c) average daily debit Entry return volume;

(f) 
the number of Originators Transmitting (d) 
average daily debit Entry return dollar
debit Entries through the Third-Party value; and
Service Provider or Third-Party Sender; (e) average daily rates of return.

(g) 
the identification of the ACH Operator SUBSECTION 2.17.2  ODFI Return Rate Reporting
through which each Direct Access Debit Upon receipt of a written request by the National
Participant Transmits Entries; and Association to the ODFI’s Chief Operating Officer,
an ODFI must provide, via traceable delivery
(h) 
a statement that the ODFI’s board of method, to the National Association within ten
directors, committee of the board of Banking Days the following information for each
directors, or its designee has approved the Originator or Third-Party Sender:
Direct Access Debit Participant.
(a) 
the complete legal name; any doing-
An ODFI must provide the National Association business-as name(s); and taxpayer
with updated information following any change to identification number(s) of the Originator
the information previously provided, including any or Third-Party Sender;
termination of the Direct Access Debit Participant.
(b) a statement as to whether the Originator
or Third-Party Sender acts as the ODFI’s

2 0 1 3 O P E R AT I N G R U L E S OR31
 ARTICLE TWO – Rights and Responsibilities of ODFIs, Their Originators and Third-Party Senders

Sending Point with direct access to the (a) a detailed plan and timeline for reducing the
ACH Operator; Originator’s or Third-Party Sender’s return
rate for Entries returned as unauthorized to
(c) 
the Originator’s or Third-Party Sender’s a rate below one percent for unauthorized
origination volume for the time period Entries within sixty days after receipt of
specified by the National Association; the National Association’s written request
for information, as described within
(d) 
the actual return rate for unauthorized Subsection 2.17.2;
Entries, in total and by SEC Code, for the
Originator or Third-Party Sender when u (a) a detailed plan and timeline for reducing
computed by either: the Originator’s or Third-Party Sender’s
return rate for Entries returned as
(i) dividing the number of debit Entries unauthorized to a rate below one percent
returned as unauthorized for the for unauthorized Entries within thirty days
preceding sixty days or two calendar after receipt of the National Association’s
months by the total number of debit written request for information, as
Entries contained within the File(s) described within Subsection 2.17.2;
in which the original Entries were
transmitted; or (b) 
the address, telephone number, contact
person of the Originator or Third-Party
(ii) dividing the number of debit Entries Sender, and, when such Originator or Third-
returned as unauthorized for the Party Sender is a privately-held company,
preceding sixty days or two calendar the following additional information:
months by the total number of debit principal owner(s) and officers of the
Entries originated for the preceding Originator or Third-Party Sender;
sixty days or two calendar months,
respectively; and (c) a description of the nature of the business
of the Originator or Third-Party Sender,
(e) a statement either: and the methods used by the Originator(s)
to obtain proper authorization for ACH
(i) 
refuting NACHA’s claim that the transactions;
Originator’s or Third-Party Sender’s
return rate for unauthorized Entries (d) the length of the ACH relationship between
exceeded one percent; or the ODFI and the Originator or Third-Party
Sender;
(ii) explaining the reason(s) causing the
Originator’s or Third-Party Sender’s (e) the date of the ODFI’s most recent review
return rate for unauthorized Entries to of the exposure limit for the Originator or
have exceeded one percent. Third-Party Sender pursuant to Subsection
2.2.2 (ODFI Risk Management); and
SUBSECTION 2.17.2.1  Additional Reporting When
the Return Threshold is Exceeded (f) date and proof of completion of the ODFI’s
u SUBSECTION 2.17.2.1  Additional ODFI Action and most recent ACH audit in accordance
Reporting When the Return Threshold is Exceeded with the requirements of these Rules and
When the Originator’s or Third-Party Sender’s Appendix Eight (Rule Compliance Audit
return rate for unauthorized Entries, as calculated Requirements).
in Subsection 2.17.2 (ODFI Return Rate Reporting),
exceeds one percent, the ODFI must also provide
the National Association with the following
information within the ten Banking Day time
frame:

uApproved April 2, 2012, Effective March 15, 2013

OR32 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SUBSECTION 2.17.2.2  ODFI Reduction of the Entry to a Receiver’s account, regardless of

Return Rate whether the name of the Receiver in the Entry
The ODFI must reduce the Originator’s or Third- matches the name associated with the account
Party Sender’s return rate for unauthorized Entries number in the Entry.
to a rate below one percent within sixty days
after receipt of the National Association’s written SUBSECTION 3.1.3  RDFI May Rely on Standard
request for information and maintain that return Entry Class Codes
rate below one percent for an additional one An RDFI may rely on the Standard Entry Class
hundred eighty days. Code contained in an Entry for the purpose of
complying with these Rules.
uThe ODFI must reduce the Originator’s or Third-
Party Sender’s return rate for unauthorized SUBSECTION 3.1.4  RDFI May Request Copy of
Entries to a rate below one percent within thirty Receiver’s Authorization of Entry from ODFI
days after receipt of the National Association’s An RDFI may request, in writing, that an ODFI
written request for information and maintain that provide a copy of the Receiver’s authorization for
return rate below one percent for an additional any Entry, subject to the limitations contained in
one hundred eighty days. these Rules on an Originator’s obligation to retain
and provide a copy of a Receiver’s authorization
for an Entry (see Subsection 2.3.2.5 – Retention
ARTICLE THREE and Provision of the Record of Authorization).
This subsection does not apply to credit Entries
Rights and for which both the Originator and Receiver are
natural persons.
Responsibilities of SUBSECTION 3.1.5  RDFI Obligation to Provide
RDFIs and Their Information About Entries

Receivers SUBSECTION 3.1.5.1  RDFI Must Provide Entry

Information for Consumer Accounts
An RDFI must provide or make available to each of
SECTION 3.1  General Rights and its Receivers the following information concerning
Responsibilities of RDFIs each credit and debit Entry to a Consumer Account
of such Receiver:
SUBSECTION 3.1.1  RDFI Must Accept Entries
An RDFI must accept Entries that comply with (a) Posting date to Receiver’s account;
these Rules and are received with respect to an
(b) Dollar amount of the Entry;
account maintained with that RDFI, subject to
its right to return Entries under these Rules. An
(c) Company name/Originator name;
Entry is deemed to be received by an RDFI on the
Banking Day on which the Entry is made available
(d) Company Entry description;
by the Receiving ACH Operator to the RDFI or to
the RDFI’s Receiving Point.
(e) Account type;
SUBSECTION 3.1.2  RDFI May Rely Solely on
(f) Account number;
Account Numbers for Posting of Entries
An RDFI may rely solely on the account number (g) Amount of any charges assessed against the
contained in an Entry for the purpose of posting account for services related to the Entry;

uApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR33
ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

(h) Balances in the Receiver’s account at the SUBSECTION 3.1.5.2  RDFI Must Provide Entry
beginning and at the close of the statement Information to Receivers of ARC, BOC, or POP
period; Entries to Non-Consumer Accounts
An RDFI must provide or make available to a
(i) For an ARC, BOC, RCK or XCK Entry, or an Receiver the contents of the Check Serial Number
IAT Entry where the Transaction Type Code field of an ARC, BOC, or POP Entry, or an IAT
field contains a value of “ARC,” “BOC,’” or Entry where the Transaction Type Code field
“RCK,” the Check Serial Number; contains a value of “ARC,” “BOC,” or “POP,” to a
non-Consumer Account.
For an MTE, POS or SHR Entry, or an IAT
(j) 
Entry where the Transaction Type Code SUBSECTION 3.1.5.3  RDFI Must Provide Payment-
field contains a value of “MTE,” “POS,” or Related Information to Receivers of CCD, CTX, CIE
“SHR,” the: and IAT Entries to Non-Consumer Accounts
Upon the request of a Receiver, an RDFI must
(i) 
Terminal identification code and/or provide to the Receiver all information contained
terminal location, as those terms are within the Payment Related Information field of an
defined in Regulation E; Addenda Record(s) Transmitted with a CCD or CTX
Entry, or a CIE or IAT Entry to a non-Consumer
(ii) Terminal city, as that term is defined Account. The RDFI must provide this information
in Regulation E; and by the opening of business on the RDFI’s second
Banking Day following the Settlement Date of the
(iii) Terminal state, as that term is defined Entry.
in Regulation E;
SUBSECTION 3.1.6  RDFI Must Provide Certain
For a POP Entry, or an IAT Entry where
(k)  Notices to the Receiver For Credit Entries Subject
the Transaction Type Code field contains a to Article 4A
value of “POP,” the: For a credit Entry subject to Article 4A, an RDFI
must notify the Receiver of each of the following:
(i) Check Serial Number;
(a) the Entry may be Transmitted through the
(ii) Terminal city, as that term is defined ACH;
in Regulation E; and
(b) the rights and obligations of the Receiver
(iii) Terminal state, as that term is defined concerning the Entry are governed by and
in Regulation E; construed in accordance with the laws of
the State of New York, unless the Receiver
(l) Address and telephone number to be used and the RDFI have agreed that the laws of
for inquiries or notices of errors preceded another jurisdiction govern their rights and
by “Direct Inquiries To” or similar language. obligations;
References to data elements contained in an Entry (c) credit given by the RDFI to the Receiver for
are further defined in Appendix Three (ACH Record the Entry as provided by Subsection 3.3.1
Format Specifications). The requirements of this (Availability of Credit Entries to Receivers)
subsection do not apply to a Receiver’s passbook is provisional until the RDFI has received
accounts which may not be accessed by electronic final settlement through a Federal Reserve
funds transfers other than preauthorized credit Bank or otherwise has received payment as
transfers. The requirements of this subsection provided for in Section 4A-403(a) of Article
apply regardless of whether or not Regulation E 4A;
imposes similar requirements on the RDFI.
(d) if the RDFI does not receive such payment
for the Entry, the RDFI is entitled to a
refund from the Receiver in the amount of

OR34 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

the credit to the Receiver’s account, and the under Subsection 1.2 (Participating DFIs Must
Originator will not be considered to have Comply with Rules), Subsection 3.2.1 (General
paid the amount of the credit Entry to the RDFI Warranties), or Subsection 3.4.5 (Specific
Receiver; and Warranties for RCK Entries).

(e) 
these Rules do not require the RDFI to SECTION 3.3  Timing Requirements for
provide the Receiver with notice that the RDFI to Make Credit and Debit Entries
RDFI has received the Entry unless the Available
RDFI has agreed to do so.
SUBSECTION 3.3.1  Availability of Credit Entries
This notice may be included as part of an to Receivers
agreement entered into by the Receiver binding
the Receiver to these Rules, or it may be provided SUBSECTION 3.3.1.1  General Rule for Availability
to the Receiver separately. of Credits
An RDFI must make the amount of each credit
SUBSECTION 3.1.7  No RDFI Obligation to Notify Entry received from its ACH Operator available
Receiver of Receipt of Entry to the Receiver for withdrawal no later than the
An RDFI is not required to notify a Receiver of Settlement Date of the Entry, subject to its right
receipt of an Entry unless otherwise provided for to return the Entry under these Rules. An RDFI
in an agreement between the RDFI and Receiver, or that reasonably suspects that a credit Entry is
required by applicable Legal Requirements which unauthorized is exempt from this requirement,
cannot be varied by these Rules or by agreement subject to applicable Legal Requirements. An RDFI
of the parties. invoking such an exemption must promptly notify
the ODFI.
SUBSECTION 3.1.8  Authorization by RDFI for
Release of Designated Data SUBSECTION 3.3.1.2  Availability for Certain Credit
An RDFI authorizes and instructs each ACH PPD Entries
Operator to provide to the National Association For a credit PPD Entry that is made available to
Designated Data related to Entries Transmitted to the RDFI by its ACH Operator by 5:00 p.m. (RDFI’s
or by the RDFI, and will hold each ACH Operator local time) on the Banking Day prior to the
harmless against any claim by the RDFI arising Settlement Date, the RDFI must make the amount
out of the ACH Operator’s compliance with such available to the Receiver for withdrawal at the
instructions. opening of business on the Settlement Date. For
purposes of this subsection, opening of business is
SECTION 3.2  General Warranties and the later of 9:00 a.m. (RDFI’s local time) or the time
Liabilities of RDFIs the RDFI’s teller facilities (including ATMs) are
available for customer account withdrawals. An
SUBSECTION 3.2.1  General RDFI Warranties RDFI that reasonably suspects that a credit Entry
An RDFI warrants to each ODFI and ACH is unauthorized is exempt from this requirement,
Operator that it has the power under applicable subject to applicable Legal Requirements. An RDFI
Legal Requirements to receive Entries as provided invoking such an exemption must promptly notify
in these Rules. the ODFI.

SUBSECTION 3.2.2  Indemnity by the RDFI for SUBSECTION 3.3.1.3  Receiver Must Credit
Breach of Warranty Originator’s Account
An RDFI shall indemnify every ODFI and A Receiver must credit the Originator with the
ACH Operator from and against any and all amount of the Entry credited to the Receiver’s
claims, demands, losses, liabilities, or expenses, account as of the Settlement Date. The Receiver
including attorneys’ fees and costs, that result has a reasonable period of time after the Entry
directly or indirectly from any breach of warranty

2 0 1 3 O P E R AT I N G R U L E S OR35
ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

is credited to the Receiver’s account to post the SUBSECTION 3.4.1.2  Rule Exception for CCD and
amount of the credit to the Originator’s account or CTX Entries to Consumer Accounts
return the Entry to the RDFI. For purposes of this The requirements of Subsection 3.1.3 (RDFI May
subsection, a Receiver is considered to act within Rely on Standard Entry Class Codes) do not apply
a reasonable period of time if the Receiver posts when CCD or CTX Entries are to a consumer
the credit or returns the Entry no later than the account.
time at which the Receiver would usually complete
the process of posting credits or returning these SUBSECTION 3.4.2  Specific Provision for
payments. A Receiver that returns an Entry DNE Entry
according to the requirements of this subsection is Receipt of a DNE Entry from a United States
not considered to have accepted the Entry. Government agency constitutes notice of death.

SUBSECTION 3.3.1.4  Credit Entries Subject to SUBSECTION 3.4.3  Specific Provisions for
Article 4A Are Provisional IAT Entries
For a credit Entry subject to Article 4A, credit
given to a Receiver by an RDFI as provided in this SUBSECTION 3.4.3.1  Rule Exception for IAT Entries
Subsection 3.3.1 (Availability of Credit Entries to The requirements of Subsection 3.8.5 (Receipt of
Receivers) is provisional until the RDFI has received Dishonored Returns) do not apply to the return of
final settlement through a Federal Reserve Bank IAT Entries.
or has otherwise received payment as provided
in Section 4A-403(a) of UCC Article 4A. If such SUBSECTION 3.4.3.2  Rule Exception for IAT Entries
settlement or payment is not received, the RDFI to Non-Consumer Accounts
is entitled to a refund from the Receiver of the The requirements of Subsection 3.1.4 (RDFI May
amount credited, and the Originator is considered Request Copy of Receiver’s Authorization of Entry
not to have paid the Receiver the amount of the from ODFI) do not apply to IAT Entries to non-
Entry. This Subsection 3.3.1.4 applies only if the Consumer Accounts.
Receiver has agreed to be bound by the Rules
contained in this Subsection 3.3.1.4. SUBSECTION 3.4.3.3 Specific Provisions for
Outbound IAT Entries
SUBSECTION 3.3.2  Timing of Debit Entries A Participating DFI acting as a Gateway assumes
An RDFI must not debit the amount of any Entry the specific responsibilities and warranties of an
to a Receiver’s account prior to the Settlement Date RDFI for each Outbound IAT Entry it Transmits.
of the Entry, even if the Effective Entry Date (as These Rules do not govern the rights and
defined in Appendix Three (ACH Record Format obligations between the Participating DFI and the
Specifications)) of the Entry is different from the foreign receiver of the Outbound IAT Entry.
Settlement Date of the Entry.
The following sections do not apply to Outbound
SECTION 3.4  Provisions for Receipt of IAT Entries:
Specific Types of Entries
(a) Subsection 3.1.4 (RDFI May Request Copy
SUBSECTION 3.4.1  Specific Provision for of Receiver’s Authorization of Entry from
CCD and CTX Entries ODFI);

SUBSECTION 3.4.1.1  Rule Exception Regarding (b) 

Subsection 3.5 (Specific Provisions for
Copy of Receiver’s Authorization Prenotifications);
The requirements of Subsection 3.1.4 (RDFI May
Request Copy of Receiver’s Authorization of Entry (c) 
Subsection 3.6 (Specific Provisions for
from ODFI) do not apply to CCD and CTX Entries. Reclamation Entries and Written Demands
for Payment).

OR36 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SUBSECTION 3.4.4  Specific Provision for (f) 

Subsection 3.1.7 (No RDFI Obligation to
MTE and SHR Entries Notify Receiver of Receipt of Entry);
The following subsections do not apply to SHR
Entries, and to MTE Entries if the ODFI and RDFI (g) 
Section 3.2 (General Warranties and
are parties to an agreement (other than these Liabilities of RDFIs);
Rules) for the provision of services relating to MTE
Entries: (h) Section 3.3 (Timing Requirements for RDFI
to Make Credit and Debit Entries Available);
(a) Subsection 3.1.4 (RDFI May Request Copy
of Receiver’s Authorization of Entry from (i) 
Subsection 3.5 (Specific Provisions for
ODFI); Prenotifications);

(b) 
Subsection 3.11 (RDFI Obligation to (j) 
Section 3.7 (RDFI Obligation to Stop
Recredit Receiver); and Payment);

(c) 
Subsection 3.13 (RDFI Right to Transmit (k) 
Section 3.8 (RDFI’s Right to Transmit
Extended Return Entries) Return Entries);

SUBSECTION 3.4.5  Specific Warranties for (l) 

Section 3.9 (Notification of Change by
RCK Entries RDFIs);
In addition to the other warranties contained
in these Rules, an RDFI receiving an RCK Entry (m) Section 3.11 (RDFI Obligation to Recredit
warrants that it will (a) display the descriptive Receiver);
information contained in the Entry on the relevant
periodic statement sent to the Receiver by the (n) 
Section 3.13 (RDFI Right to Transmit
RDFI, and (b) accord the Receiver the same rights Extended Return Entries);
with respect to the RCK Entry as are provided for
(o) Section 8.12 (“Banking Day”);
items under Revised Article 4 of the 1990 Official
Text of the Uniform Commercial Code, except as
(p) Section 8.38 (“File”);
otherwise provided in the RDFI’s agreement with
the Receiver.
(q) Section 8.63 (“Person”);
SUBSECTION 3.4.6  Specific Provisions for
(r) Appendix Four (Return Entries);
TRC and TRX Entries (Check Truncation)
The following sections do not apply to TRC and (s) Appendix Five (Notification of Change);
TRX Entries:
(t) Appendix Seven (Compensation Rules);
(a) Section 1.7 (Choice of Law);
(u) 
Appendix Eight (Rule Compliance Audit
(b) 
Subsection 3.1.1 (RDFI Must Accept Requirements);
Entries);
(v) Appendix Nine (Arbitration Procedures).
(c) Subsection 3.1.2 (RDFI May Rely Solely on
Account Numbers for Posting of Entries); SUBSECTION 3.4.7  Specific Provision for
XCK Entries
(d) Subsection 3.1.4 (RDFI May Request Copy
The Subsection 3.1.4 (RDFI May Request Copy of
of Receiver’s Authorization of Entry from
Receiver’s Authorization of Entry from ODFI) does
ODFI);
not apply to XCK Entries.
(e) 
Subsection 3.1.5 (RDFI Obligation to
Provide Information About Entries);

2 0 1 3 O P E R AT I N G R U L E S OR37
ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SECTION 3.5  Specific Provisions for 2.10 (Reclamation Entries and Written
Prenotifications Demands for Payment) and not
returned by the RDFI; or
An RDFI that receives a Prenotification Entry
must verify that the account number contained
(ii) 
a written demand for payment from
in the Prenotification is for a valid account. If
the ODFI or Originator and has a
the Prenotification does not contain a valid
reasonable opportunity to act upon
account number, or is otherwise erroneous or
such demand.
unprocessable, then the RDFI must Transmit either
(a) a Return Entry, or (b) a Notification of Change.
If the RDFI makes a payment pursuant to this
Section 3.6 that is subject to a subsequent claim of
SECTION 3.6  Specific Provisions the United States Government under 31 C.F.R. Part
for Reclamation Entries and Written 210, the RDFI is entitled to reimbursement by the
Demands for Payment Originator in accordance with Subsection 2.10.5
(Superiority of United States Government Claims).
SUBSECTION 3.6.1  RDFI Right to Debit a
Receiver’s Account with Respect to Reclamation
SUBSECTION 3.6.4  Alteration of Reclamation
Entry
Provisions by Agreement – RDFI
An RDFI may debit a Receiver’s account with
The liability provisions contained within
respect to a Reclamation Entry that meets the
this Section 3.6 may be altered, amended, or
requirements of Section 2.10 (Reclamation Entries
superseded by a written agreement between the
and Written Demands for Payment) without regard
Originator and RDFI only if the agreement clearly
to any Person other than the Receiver having an
and conspicuously states on its face that it is a
interest in the account identified in the Reclamation
master agreement, that both the Originator and
Entry.
RDFI consider it to be a master agreement, and
that it is applicable to all payments subject to
SUBSECTION 3.6.2  Liability of RDFI for
the this Section 3.6, notwithstanding any other
Reclamation Entries and Written Demands for
Payment provision of these Rules. No provision of these
Rules prevents an RDFI from expressly agreeing
An RDFI shall be liable to the Originator for the
in a master agreement that the liability provisions
amount of each Reclamation Entry or written
of this Section 3.6 may be altered, amended, or
demand for payment properly initiated by the
superseded on a Receiver-by-Receiver basis.
ODFI pursuant to  Section 2.10 (Reclamation
Entries and Written Demands for Payment) unless
the Reclamation Entry or Written Demand for SECTION 3.7  RDFI Obligation to Stop
Payment is properly returned by the RDFI. Payment
SUBSECTION 3.7.1  RDFI Obligation to Stop
SUBSECTION 3.6.3  Amount of RDFI Liability for Payment of Entries to Consumer Accounts
Reclamation Entries and Written Demands for
Payment SUBSECTION 3.7.1.1  RDFI Obligation to Stop
An RDFI’s liability under Subsection 3.6.2 (Liability Payment of Recurring Entries
of RDFI for Reclamation Entries and Written An RDFI must honor a stop payment order provided
Demands for Payment) shall be the lesser of: by a Receiver, either verbally or in writing, to
the RDFI at least three Banking Days before the
(a) the amount of any payments to which the scheduled date of any debit Entry to a Consumer
Receiver was not entitled; or Account other than a Single Entry. An RDFI may
in its discretion honor such a stop payment order
(b) the amount in the Receiver’s account at the received within such three Banking Day period.
time the RDFI receives: An RDFI shall have no liability or responsibility to
any Originator, ODFI, or other Person having any
(i) 
a Reclamation Entry initiated by the interest in such Entry for honoring a stop payment
ODFI in accordance with Section order in accordance with this subsection.

OR38 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SUBSECTION 3.7.1.2  RDFI Obligation to Stop payment order prior to acting on the debit Entry.
Payment of Single Entries The RDFI must comply with a verbal stop payment
An RDFI must honor a stop payment order provided order only for a period of fourteen calendar days
by a Receiver, either verbally or in writing, to the unless the order is confirmed in writing within
RDFI at such time and in such manner as to allow that fourteen-day period. A written stop payment
the RDFI a reasonable opportunity to act upon the order regarding any debit Entry initiated or to be
order prior to acting on an ARC, BOC, POP, or RCK initiated to a non-Consumer Account will remain
Entry, or a Single Entry IAT, PPD, TEL, or WEB in effect for six months unless it is renewed in
Entry to a Consumer Account. writing.

SUBSECTION 3.7.1.3  RDFI May Require Written SECTION 3.8  RDFI’s Right to Transmit
Confirmation of Stop Payment Orders Return Entries
An RDFI may require written confirmation of a An RDFI may return an Entry for any reason,
verbal stop payment order under this Subsection except as otherwise provided for in Subsection
3.7.1 within fourteen days of the verbal stop 3.8.1 (Restrictions on RDFI’s Right to Transmit
payment order, provided that the RDFI notifies Return Entries). An RDFI must comply with the
the Receiver of this requirement and provides an requirements of Appendix Four (Return Entries)
address to which the written confirmation should for each Return Entry it initiates.
be sent at the time the verbal order is provided. If
the RDFI requires written confirmation, the verbal An RDFI must Transmit a Return Entry to its ACH
stop payment order will cease to be binding after Operator by the ACH Operator’s deposit deadline
fourteen days. for the Return Entry to be made available to the
ODFI no later than the opening of business on
For an order to stop all future payments relating the second Banking Day following the Settlement
to a specific authorization involving a specific Date of the original Entry, except as otherwise
Originator, an RDFI may require a Receiver to provided in Subsection 3.8.3 (Exceptions to Timing
confirm in writing that the Receiver has revoked Requirements for Return Entries) and Section
the authorization given to the Originator. 3.13 (RDFI Right to Transmit Extended Return
Entries). A Return Entry which is rejected by an
SUBSECTION 3.7.1.4  Effective Period of Stop ACH Operator does not satisfy or extend the timing
Payment Orders requirements contained in this Section 3.8.
A stop payment order will remain in effect until
the earlier of: SUBSECTION 3.8.1  Restrictions on RDFI’s Right
to Transmit Return Entries
(a) the withdrawal of the stop payment order
by the Receiver; or SUBSECTION 3.8.1.1  RDFI May Not Return an
Entry Due to the Type of Entry
(b) 
the return of the debit Entry, or, where An RDFI may not return an Entry because it is a
a stop payment order applies to more particular type of Entry, unless expressly provided
than one debit Entry relating to a for in Subsection 3.8.2 (Exceptions to Restrictions
specific authorization involving a specific on RDFI’s Right to Transmit Return Entries).
Originator, the return of all such debit
Entries. SUBSECTION 3.8.1.2  RDFI May Not Return an
Entry Based on MICR Data
SUBSECTION 3.7.2  RDFI Obligation to Stop An RDFI may not return an Entry to a Transaction
Payment of Entries to Non-Consumer Accounts Account based exclusively on data which were
An RDFI must honor a stop payment order regarding accurately obtained from the on-us field of the
any debit Entry initiated or to be initiated to a non- MICR line of a Check for the account, unless the
Consumer Account that is provided by a Receiver RDFI had previously initiated a Notification of
at such time and in such manner as to allow the Change that was not properly acted upon.
RDFI a reasonable opportunity to act upon the stop

2 0 1 3 O P E R AT I N G R U L E S OR39
ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SUBSECTION 3.8.2  Exceptions to Restrictions on SUBSECTION 3.8.3.4  Timing Requirements for

RDFI’s Right to Transmit Return Entries Return of XCK Entries
An RDFI may return: An RDFI must Transmit a Return Entry relating
to an XCK Entry to its ACH Operator by the ACH
(a) an XCK Entry for any reason; and, Operator’s deposit deadline for the Return Entry
to be made available to the ODFI no later than the
(b) 
any Entry received (including a opening of business on the Banking Day following
Prenotification) that concerns any account the sixtieth calendar day following the Settlement
that is not a Transaction Account maintained Date of the XCK Entry.
with that RDFI.
SUBSECTION 3.8.3.5  Late Return Entries for CCD
SUBSECTION 3.8.3  Exceptions to Timing or CTX Entries with ODFI Agreement
Requirements for Return Entries If an RDFI receives written notification from a
Receiver that a CCD or CTX Entry that was debited
SUBSECTION 3.8.3.1  Timing Requirements of
to the Receiver’s account was, in whole or in part,
Return of Credit Entry Subject to Article 4A
not authorized by the Receiver, the RDFI may
An RDFI must Transmit a Return Entry relating Transmit a Return Entry to the ODFI after the time
to a credit Entry subject to Article 4A to its ACH for return has expired, provided that the ODFI
Operator prior to the time the RDFI accepts the agrees, either verbally or in writing, to accept the
credit Entry as provided for under Article 4A, late Return Entry. The Return Entry must be in
unless: the amount of the debit Entry and must otherwise
comply with the requirements of this Section 3.8
(a) the Receiver of the Entry does not have an and Appendix Four (Return Entries).
account with the RDFI;
SUBSECTION 3.8.4  RDFI Must Return Unposted
(b) the Receiver’s account has been closed; or
Credit Entries
An RDFI must return all credit Entries that are
(c) 
the RDFI is not permitted by Legal
not credited or otherwise made available to its
Requirements to receive credits for the
Receivers’ accounts. The RDFI must Transmit such
Receiver’s account.
a Return Entry to its ACH Operator by the ACH
Operator’s deposit deadline for the Return Entry
SUBSECTION 3.8.3.2  Timing Requirements for
Credit Entries Refused by Receiver to be made available to the ODFI no later than the
opening of business on the second Banking Day
An RDFI must return any credit Entry that is
following the Settlement Date of the original Entry.
refused by a Receiver. The RDFI must Transmit any
such Return Entry to its ACH Operator by the ACH
SUBSECTION 3.8.5  Receipt of Dishonored
Operator’s deposit deadline for the Return Entry
Returns
to be made available to the ODFI no later than the
opening of business on the second Banking Day SUBSECTION 3.8.5.1  RDFI May Correct
following the RDFI’s receipt of notification from Dishonored Returns
the Receiver that it has refused the Entry. An RDFI may Transmit a corrected Return Entry
to its ACH Operator for any Return Entry that
SUBSECTION 3.8.3.3  Timing Requirements for was dishonored by the ODFI (as permitted under
Return of RCK Entries Subsection 2.12.5.1 (Dishonor of Return by ODFI),
An RDFI must Transmit a Return Entry relating to Item (b)) because information contained in one
an RCK Entry to its ACH Operator by midnight or more fields of the Return Entry is incorrect or
of the RDFI’s second Banking Day following the missing. The RDFI must include the dishonored
Banking Day of the receipt of the RCK Entry. return information received from the ODFI in

OR40 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

the dishonored Return Entry and must ensure (b) the COR Entry is Transmitted within two
the corrected Return Entry otherwise complies Banking Days of the Settlement Date of the
with the requirements of Appendix Four (Return Entry to which the Notification of Change
Entries). The RDFI must Transmit the corrected relates, except for Notifications of Change
Return Entry to its ACH Operator within two due to merger, acquisition, or other similar
Banking Days after the Settlement Date of the events.
dishonored Return Entry.
SUBSECTION 3.9.2  RDFI May Correct a Refused
SUBSECTION 3.8.5.2  RDFI May Contest Notification of Change
Dishonored Returns If a COR Entry is refused by the ODFI, an RDFI may
An RDFI may Transmit a contested dishonored transmit a corrected COR Entry to the Receiving
Return Entry that corresponds to the reason for ACH Operator within five Banking Days after the
the dishonored Return Entry if: Settlement Date of the refused COR Entry.

(a) 
the original Return Entry was, in fact, SUBSECTION 3.9.3  RDFI Warranties for
returned within the time limits established Notifications of Change
by these Rules; In addition to the other warranties contained in
these Rules, an RDFI that transmits a COR Entry,
(b) 
the original Return Entry was not a including a corrected COR Entry, warrants to each
duplicate Entry; ODFI and ACH Operator that:

(c) the original Return Entry was complete and (a) the information contained within the COR
contained no errors; or Entry or corrected COR Entry is correct;
and
(d) the dishonored Return Entry was misrouted
or untimely. (b) 
if the change relates to the Receiver’s
account number, the Receiver has
The RDFI must Transmit a contested dishonored authorized the change, if authorization is
Return Entry to the ACH Operator within two required, and the RDFI has complied with
Banking Days after the Settlement Date of the any applicable Legal Requirements for
dishonored Return Entry and must ensure the such authorization.
contested dishonored Return Entry otherwise
complies with the requirements of Appendix Four The RDFI’s warranty supersedes and renders
(Return Entries). inoperative any similar warranty (but not any
other warranty) of the ODFI contained within
SECTION 3.9  Notification of Change Subsection 2.4.1 (General ODFI Warranties).
by RDFIs
SUBSECTION 3.9.4  Indemnity by RDFI for Breach
SUBSECTION 3.9.1  General Rule for Notification of Notification of Change Warranties
of Change (COR Entry)
An RDFI shall indemnify every ODFI and ACH
An RDFI may Transmit a Notification of Change Operator from and against any and all claims,
(also known as a COR Entry) to its ACH Operator demands, losses, liabilities, or expenses, including
provided that: attorneys’ fees and costs that result directly or
indirectly from any breach of the warranties
(a) 
the COR Entry complies with the contained in Subsection 3.9.3 (RDFI Warranties for
requirements of Appendix Five (Notification Notifications of Change).
of Change); and

2 0 1 3 O P E R AT I N G R U L E S OR41
ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

SECTION 3.10  Specific Provisions for accordance with Section 3.12 (Written Statement
Acknowledgment (ACK and ATX) Entries of Unauthorized Debit), and such notification is
received within fifteen calendar days from the date
An RDFI that receives a credit CCD or CTX Entry
the RDFI sends or makes available to the Receiver
may Transmit an ACK or ATX Entry, respectively,
information related to the debit Entry in accordance
complying with the requirements of Appendix Six
with Subsection 3.1.5 (RDFI Obligation to Provide
(Acknowledgment Entries), to its ACH Operator
Information About Entries).
for Transmittal to the appropriate ODFI. The RDFI
must Transmit the ACK or ATX Entry to its ACH
u The RDFI’s obligation to recredit the Receiver’s
Operator by the ACH Operator’s deposit deadline
account for a debit Entry that is part of an
for the ACK or ATX Entry to be made available to
Incomplete Transaction does not apply when a
the ODFI no later than the opening of business on
partial or erroneous payment was made to the
the second Banking Day following the Settlement
intended third-party payee on the Receiver’s behalf.
Date of the CCD or CTX Entry to which the ACK
or ATX Entry relates.
SUBSECTION 3.11.2  RDFI Specific Obligations to
Recredit Accounts for ARC, BOC, POP, RCK and
SECTION 3.11  RDFI Obligation to IAT Debit Entries
Recredit Receiver
An RDFI must recredit the accountholder for SUBSECTION 3.11.2.1  RDFI Obligation to Recredit
Non-Consumer Accounts for ARC, BOC and
a debit Entry that was, in whole or in part, not
POP Entries
properly authorized under these Rules, as required
by these Rules, applicable Legal Requirements, An RDFI must promptly recredit the amount of
or agreement between the RDFI and the account an ARC, BOC, or POP Entry to a non-Consumer
holder. This recredit requirement does not Account of a Receiver if it receives notification
apply if the accountholder is a Receiver that has from the Receiver in accordance with Section 3.12
waived any right to recredit in accordance with (Written Statement of Unauthorized Debit), and
the requirements of Subsection 3.11.4 (Receiver’s such notification is received within fifteen calendar
Waiver of RDFI’s Recredit Obligation). days from the date the RDFI sends or makes
available to the Receiver information related to the
uAn RDFI must recredit the accountholder to the debit Entry in accordance with Subsection 3.1.5
extent provided in this Section 3.11 for (a) a debit (RDFI Obligation to Provide Information About
Entry that was, in whole or in part, not properly Entries).
authorized under these Rules, as required by these
Rules, applicable Legal Requirements, or agreement SUBSECTION 3.11.2.2  RDFI Obligation to Recredit
between the RDFI and the account holder; and for ARC, BOC and RCK Entries Regarding Stop
Payment Orders
(b) a debit Entry to a Receiver’s account that is
part of an Incomplete Transaction. This recredit An RDFI must promptly recredit the amount of
requirement does not apply if the accountholder an ARC, BOC, or RCK Entry to the account of a
is a Receiver that has waived any right to recredit Receiver if, at the time that any such Entry was
in accordance with the requirements of Subsection paid by the RDFI, a stop payment order was in
3.11.4 (Receiver’s Waiver of RDFI’s Recredit force with respect to (a) the Check that was used
Obligation). as an Eligible Source Document for the ARC or
BOC Entry, or (b) the item to which the RCK Entry
SUBSECTION 3.11.1  RDFI General Obligation to relates. The RDFI is not required to obtain a
Recredit Consumer Accounts Written Statement of Unauthorized Debit.
An RDFI must promptly recredit the amount of a
debit Entry to a Consumer Account of a Receiver, SUBSECTION 3.11.2.3  RDFI Obligation to Recredit
for Debit IAT Entries
regardless of the SEC Code of the debit Entry,
if it receives notification from the Receiver in An RDFI must promptly recredit the amount of
a debit IAT Entry to the account of a Receiver

uApproved April 2, 2012, Effective March 15, 2013

OR42 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

if it receives notification from the Receiver in Except for waivers and exclusions complying
conformance with Section 3.12 (Written Statement with the requirements of this subsection, an
of Unauthorized Debit), and such notification is RDFI may not act on any other purported waiver
received within fifteen calendar days from the of any obligation under these Rules to recredit
date the RDFI sends or makes available to the a Receiver’s account for unauthorized debits. If
Receiver information related to the debit Entry in an Originator delivers a waiver, with a copy, to
accordance with Subsection 3.1.5 (RDFI Obligation the RDFI, the RDFI must acknowledge receipt on
to Provide Information About Entries). An RDFI the copy of the waiver and promptly deliver or
may not recredit a Receiver’s account if doing so provide that copy to the Originator if requested by
is inconsistent with U.S. Legal Requirements, as the Originator in writing.
provided in Subsection 1.2.1 (Effect of Illegality).
SECTION 3.12  Written Statement of
SUBSECTION 3.11.3  RDFI’s Recredit Obligation Unauthorized Debit
Not Exclusive
An RDFI’s obligation to recredit a Receiver under SUBSECTION 3.12.1  Unauthorized Debit Entry
this Section 3.11 is in addition to any other For purposes of this Section 3.12, a debit Entry
obligation provided under Regulation E of the was not authorized by the Receiver if:
Board of Governors of the Federal Reserve System
or other applicable Legal Requirements. (a) the authorization requirements of Section
2.3 (Authorization and Notice of Entries)
SUBSECTION 3.11.4  Receiver’s Waiver of RDFI’s were not met;
Recredit Obligation
An RDFI shall have no obligation to recredit a (b) the debit Entry was initiated in an amount
Receiver if it has received a waiver signed by the different than that authorized by the
Receiver, and complying with the requirement Receiver; or
of this subsection, in sufficient time and in such
manner for the RDFI to reasonably act on it, subject (c) the debit Entry was initiated for settlement
to Legal Requirements. Such a waiver with respect earlier than authorized by the Receiver.
to one or more specific debit Entries initiated to
the Receiver’s account must: An unauthorized debit Entry does not include a
debit Entry initiated with fraudulent intent by the
(a) 
be in writing in a document entitled Receiver or any Person acting in concert with the
“WAIVER WITH RESPECT TO PRE- Receiver.
ARRANGED DEBIT”;
SUBSECTION 3.12.2  Improper ARC, BOC, POP
(b) specify the amount of each Entry to which and RCK Debit Entries
the waiver applies; For purposes of this Section 3.12, a debit Entry
was improper if it was:
(c) 
specify the approximate date on which
each Entry was initiated by the Originator; (a) an ARC, BOC or POP Entry for which:

(d) specify the Originator number designated (i) 

the source document used for the
in each Entry; and Entry was not an Eligible Source
Document,: or
(e) 
specifically state in substance that the
Receiver waives any right to have a (ii) the Check that was used as a source
designated RDFI credit the amount of the document for the Entry was paid by
Entry or Entries to the Receiver’s account the RDFI;
due to error, unless the error was made by
the RDFI. (b) an ARC or BOC Entry for which:

2 0 1 3 O P E R AT I N G R U L E S OR43
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

(i) 
notice was not provided by the SUBSECTION 3.12.4  RDFI Must Accept Written
Originator in accordance with Statement of Unauthorized Debit
Subsection 2.5.1.2 (Authorization An RDFI must accept a Written Statement of
of ARC Entries by Notification) or Unauthorized Debit from a Receiver with respect
Subsection 2.5.2.2 (Authorization to any:
of BOC Entries by Notification), as
applicable; or (a) unauthorized or improper debit Entry to a
Consumer Account;
(ii) 
the amount of the Entry was not
accurately obtained from the Eligible (b) any unauthorized or improper ARC, BOC,
Source Document; or POP Entry to a non-Consumer Account;
and
(c) an RCK Entry for which:
(c) any unauthorized IAT Entry.
(i) 
notice stating the terms of the RCK
Entry policy was not provided by u (a) unauthorized or improper debit Entry to a
the Originator in accordance with Consumer Account;
Subsection 2.5.13.2 (Authorization of
RCK Entries by Notification); (b) 
unauthorized or improper ARC, BOC, or
POP Entry to a non-Consumer Account;
(ii) 
the item to which the RCK Entry
relates is not an eligible item; (c) unauthorized IAT Entry; and

(iii) all signatures on the item to which the (d) 

Incomplete Transaction to a Consumer
RCK Entry relates are not authorized Account.
or authentic;
The Written Statement of Unauthorized Debit
(iv) 
the item to which the RCK Entry must be signed or similarly authenticated by
relates has been altered; the Receiver, submitted within the time frames
provided by these Rules, and otherwise conform
(v) the amount of the RCK Entry was not to the requirements of this Section 3.12.
accurately obtained from the item; or
The Written Statement of Unauthorized Debit must
(vi) both the RCK Entry and the item to include the following minimum information for
which the RCK Entry relates have each Entry for which recredit is requested by the
been paid. Receiver:

u SUBSECTION 3.12.3 Incomplete Transaction (e) Receiver’s printed name and signature;
For purposes of this Section 3.12, a transaction is
an Incomplete Transaction if it involves a debit (f) Receiver’s account number;
Entry authorized by a Receiver for the purpose of
(g) 
Identity of the party (i.e., the payee)
funding a corresponding payment to a third-party
debiting the account, as provided to the
payee, but the Originator, Third-Party Sender or
Receiver;
ODFI of the debit Entry failed to make or complete
the corresponding payment to the intended third-
u (g) Identity of the party (i.e., the payee) debiting
party payee. An Incomplete Transaction does not
the account, as provided to the Receiver,
include a partial or erroneous payment made to
and, if different, the name of the intended
the intended third-party payee.
third-party payee;

uApproved April 2, 2012, Effective March 15, 2013

OR44 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE THREE – Rights and Responsibilities of RDFIs and Their Receivers

(h) Date the Entry was posted to the account; SECTION 3.13  RDFI Right to Transmit
Extended Return Entries
(i) Dollar amount of Entry;
SUBSECTION 3.13.1  RDFI May Transmit
(j) Reason for return; Extended Return Entries
An RDFI may Transmit an Extended Return
(k) Signature date; Entry with respect to any debit Entry for which
it recredits a Receiver’s account in accordance
(l) 
Receiver assertion that the Written
with Section 3.11 (RDFI Obligation to Recredit
Statement of Unauthorized Debit is true
Receiver), provided that:
and correct; and
(a) 
no error was made by the RDFI in the
(m) 
Receiver assertion that the Receiver is
debiting of the original Entry to the
an authorized signer or has corporate
Receiver’s account, except with respect to
authority to act on the account.
a stop payment order; and
The Written Statement of Unauthorized Debit must
(b) 
the RDFI Transmits the Extended Return
be dated on or after the Settlement Date of the
Entry to its ACH Operator by its deposit
Entry(ies) for which recredit is requested.
deadline for the Extended Return Entry to
More than one unauthorized debit Entry from a be made available to the ODFI no later than
single Originator may be documented on a Written the opening of business on the Banking
Statement of Unauthorized Debit, provided that all Day following the sixtieth calendar day
of the information detailed above is provided for following the Settlement Date of the
each debit Entry for which the Receiver is seeking original Entry.
recredit.
The Extended Return Entry must comply with the
requirements of Appendix Four (Return Entries).
SUBSECTION 3.12.5  Retention of Written
Statement of Unauthorized Debit
SUBSECTION 3.13.2  RDFI Warranty for Extended
An RDFI must retain the original or a reproducible
Return Entries
copy of each Written Statement of Unauthorized
In addition to the other warranties contained in
Debit for at least one year from the Settlement Date
these Rules, an RDFI Transmitting an Extended
of the Extended Return Entry(ies) to which the
Return Entry in accordance with this Section
Written Statement of Unauthorized Debit relates.
3.13 warrants to each ODFI, ACH Operator, and
Gateway that, prior to initiating the Extended
SUBSECTION 3.12.6  Copy of Written Statement
of Unauthorized Debit Return Entry, the RDFI obtained from the Receiver
a Written Statement of Unauthorized Debit
An RDFI Transmitting an Extended Return Entry as
complying with Section 3.12 (Written Statement of
provided in Section 3.13 (RDFI Right to Transmit
Unauthorized Debit). This Subsection 3.13.2 does
Extended Return Entries) must provide to an ODFI
not apply to Extended Return Entries related to an
a copy of the Written Statement of Unauthorized
RDFI’s recredit obligation in Subsection 3.11.2.2
Debit obtained from the Receiver in accordance
(RDFI Obligation to Recredit for ARC, BOC and
with this Section 3.12 within ten Banking Days
RCK Entries Regarding Stop Payment Orders).
after receiving a written request from the ODFI,
provided that such request is received by the RDFI
SUBSECTION 3.13.3  Indemnity of RDFI for
within one year of the date of the initiation of the
Breach of Extended Return Entries Warranty
Extended Return Entry.
An RDFI shall indemnify every ODFI, ACH
Operator, and Gateway from and against any
and all claims, demands, losses, liabilities, or

2 0 1 3 O P E R AT I N G R U L E S OR45
ARTICLE FOUR – Rights and Responsibilities of ACH Operators

expenses, including attorneys’ fees and costs, SUBSECTION 4.1.4  ACH Operator Must Conduct
resulting directly or indirectly from the breach of Risk Management
the warranty contained in Subsection 3.13.2 (RDFI An ACH Operator must evaluate the credit-
Warranty for Extended Return Entries). worthiness of, and apply risk control measures to,
each of its Participating DFIs.

ARTICLE FOUR SUBSECTION 4.1.5  ACH Operator Must Comply

With Federal Reserve Policy on Settlement
Rights and An ACH Operator must comply with the Federal
Reserve’s Policy Statement on Privately Operated
Responsibilities of Multilateral Settlement Systems, as applicable.

ACH Operators SUBSECTION 4.1.6  ACH Operator Must Comply

With National Performance Standards
An ACH Operator must comply with any National
SECTION 4.1  General Responsibilities of ACH Operator Performance Standards of the
ACH Operators National Association.

SUBSECTION 4.1.1  ACH Operator Must Enter SUBSECTION 4.1.7  ACH Operator Must Allow
Agreement with National Association Inter-Operator Exchanges
An ACH Operator that is not a Federal Reserve An ACH Operator must exchange Files and Entries
Bank must execute an agreement annually with with all other ACH Operators.
the National Association in which the ACH
Operator agrees to perform all the functions of an SECTION 4.2  Processing Obligations of
ACH Operator and comply with all the obligations ACH Operators
of an ACH Operator described in these Rules.
An ACH Operator must promptly process and edit
Files and Entries in accordance with these Rules.
SUBSECTION 4.1.2  ACH Operator Must Comply
With the Rules
SUBSECTION 4.2.1  Settlement Date
An ACH Operator must comply with these Rules
(except to the extent that the Rules are inconsistent A Receiving ACH Operator must insert the
with the policies or practices of the Federal Reserve appropriate Settlement Date.
Banks) and applicable Legal Requirements.
SUBSECTION 4.2.2  Return or Rejection
SUBSECTION 4.1.3  ACH Operator Must Enter An ACH Operator must return any Entry that does
Agreements with Participating DFIs not meet the acceptance criteria of Appendix
An ACH Operator must execute agreements with Two (Specifications for Data Acceptance by ACH
a minimum of twenty independent Participating Operators), or reject the entire batch or File
DFIs (not owned or controlled by the same containing such Entry.
holding company) that bind them to the ACH
Operator’s rules and these Rules, provided that an SUBSECTION 4.2.3  Timely Delivery
ACH Operator that is a Federal Reserve Bank is An ACH Operator must Transmit or otherwise
not required to bind a Participating DFI to any make available Entries to the appropriate ACH
provision of these Rules that is not incorporated Operator or Participating DFI in accordance with
by the Federal Reserve Banks Operating Circular 4 agreed upon processing and delivery schedules.
on Automated Clearing House Items.
SUBSECTION 4.2.4  File Repair – Other ACH
Operator
An Originating ACH Operator must remake any File
rejected by another ACH Operator in accordance
with Subsection 4.2.2 (Return or Rejection).

OR46 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE FOUR – Rights and Responsibilities of ACH Operators

SUBSECTION 4.2.5  File Repair – RDFI SUBSECTION 4.3.3  Time Limitations on Initiation
A Receiving ACH Operator must remake any File of Reversing Files
rejected by an RDFI. An ACH Operator must Transmit each Reversing
File and, if applicable, a corresponding Correcting
SUBSECTION 4.2.6  Return and Rejection of TRC File, within twenty-four hours of the discovery of
Entries or TRX Entries the duplication or error, and also in time to be
An Originating ACH Operator must reject any Transmitted to the RDFI within five Banking Days
batch of Entries identified by the TRC or TRX after the Settlement Date of the Erroneous File.
Standard Entry Class Code that is not originated
by an ODFI that is a participant in a Check SUBSECTION 4.3.4  Notification by ACH Operator
Truncation Program and must promptly notify the of Reversing Files
ODFI of such action. A Receiving ACH Operator A Receiving ACH Operator initiating a Reversing
must return any Entry identified by the TRC or File must notify each Originating ACH Operator
TRX Standard Entry Class Code if the RDFI is directly concerned of the duplication or error at or
not a Check Truncation Program participant. An prior to the time of initiation of the Reversing File.
ACH Operator must determine whether an ODFI An Originating ACH Operator initiating a Reversing
or RDFI is a participant in a Check Truncation File must notify each ODFI directly concerned of
Program solely from the information provided to the duplication or error at or prior to the time of
the ACH Operator by the administrator of each initiation of the Reversing File.
Check Truncation Program.
SUBSECTION 4.3.5  Indemnification for
SUBSECTION 4.2.7  Debit and Credit Totals Reversing Files
An ACH Operator must total the debit and credit An ACH Operator that initiates a Reversing File or
activity received from and Transmitted to each Correcting File shall indemnify each Participating
other ACH Operator and Participating DFI during DFI and ACH Operator from and against any and all
each Banking Day. claims, demands, losses, liabilities, and expenses,
including attorneys’ fees and costs, that result
SUBSECTION 4.2.8  Calculation of Settlement directly or indirectly from the debiting or crediting
Amounts of any Entry in the Reversing File or corresponding
An ACH Operator must calculate the settlement Correcting File to the Receiver’s account.
amounts for each Banking Day for all Entries
processed under these Rules. SECTION 4.4  ACH Operator Not Agent of
Participating DFI
SECTION 4.3  Reversing Files An ACH Operator is not an agent of a Participating
DFI. For a credit Entry subject to Article 4A, where
SUBSECTION 4.3.1  General Rule for Reversing the terms of the Entry originated by the ODFI differ
Files
from the terms of the Entry received by the RDFI,
An ACH Operator may initiate a Reversing File the ODFI is obligated for the Entry it originated.
if it has mistakenly initiated an Erroneous File. This section does not affect the liability of an ACH
A Reversing File must reverse all Entries of an Operator as otherwise provided in these Rules.
Erroneous File.
SECTION 4.5  ACH Operator Must Retain
SUBSECTION 4.3.2  Obligation to Initiate Records of Entries
Correcting Files Corresponding to Reversing
Files An ACH Operator must retain a Record of all
An ACH Operator initiating a Reversing File to Entries, Return Entries, and Extended Return
correct an Erroneous File must concurrently Entries received or Transmitted by it for one
Transmit a Correcting File corresponding to the year from the date the Entry was received or
Erroneous File, unless the Erroneous File was a Transmitted. The ACH Operator must provide a
duplicate. printout or other reproduction of the information

2 0 1 3 O P E R AT I N G R U L E S OR47
A R T I C L E F I V E – R i g h t s a n d R e s p o n s i b i l i t i e s o f G a t e w a y s f o r I AT E n t r i e s

relating to a particular Entry if requested to do so SECTION 4.8  Optional Services

by the Participating DFI or other ACH Operator that An ACH Operator may provide optional services
Transmitted or received the Entry. that do not inconvenience or adversely affect the
rights of other ACH Operators, or Participating
SECTION 4.6  Requirement to Provide DFIs that do not use optional services.
Designated Data to National Association
SUBSECTION 4.6.1  General Obligation
An ACH Operator must provide Designated Data ARTICLE FIVE
to the National Association in accordance with
the requirements of this Section 4.6. No ACH Rights and
Operator is obligated to provide any other data to
the National Association.
Responsibilities of
SUBSECTION 4.6.2  Timing and Method
Gateways for IAT
An ACH Operator must provide Designated Data
to the National Association in accordance with
Entries
timelines and procedures that are mutually agreed
between the ACH Operator and the National SECTION 5.1  Responsibilities of
Association. Gateways
SUBSECTION 4.6.3  Exception to Obligation to SUBSECTION 5.1.1 Gateway Must Enter
Provide Designated Data Agreement with ODFI or Gateway’s Customer
An ACH Operator may suspend, upon one A Gateway that Transmits Outbound IAT Entries
Banking Day’s prior written notice, the sharing of must have an agreement with either (i) the ODFI
Designated Data with the National Association, if of the Outbound IAT Entry; or (ii) a customer
the National Association is in material breach of its of the Gateway that instructs the Gateway to
obligations under Section 6.1 (Use and Disclosure receive Outbound IAT Entries on its behalf for re-
of Designated Data by the National Association), Transmission to a foreign country.
until such time as the National Association cures
the breach and implements policies, procedures, SUBSECTION 5.1.2  Gateway Must Comply with
and systems as may be necessary to prevent a U.S. Legal Requirements
recurrence of the breach. A Gateway must comply with applicable U.S.
Legal Requirements, including all requirements
SECTION 4.7  Automated Accounting administered by the U.S. Department of the
Advices Treasury Office of Foreign Assets Control and U.S.
An ACH Operator may provide ACH accounting Financial Crimes Enforcement Network in effect at
information in machine readable format to any given time.
facilitate the automation of accounting information
for Participating DFIs. The ACH Operator provides SUBSECTION 5.1.3 Gateway Must Notify
accounting information in a separate file and in Intended RDFI of Unlawful Inbound Payment
Transaction
standard record formats with specific field contents
as indicated in Appendix Three (ACH Record Except to the extent prohibited by applicable
Format Specifications). For Automated Accounting Legal Requirements, a Gateway must (1) notify
Advices, the ACH Operator is identified in the ACH the intended RDFI of any Inbound payment
Record as the company as well as the ODFI. transaction that has been blocked and/or rejected
by the Gateway because the origination of an
Inbound IAT Entry for such transaction would
violate U.S. Legal Requirements, and (2) provide
the intended RDFI with the following minimum

OR48 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E F I V E – R i g h t s a n d R e s p o n s i b i l i t i e s o f G a t e w a y s f o r I AT E n t r i e s

information from the payment transaction within SUBSECTION 5.1.6 Gateway Action on Receipt of
five banking days of blocking or rejecting the Notification of Change (NOC) Related to Inbound
payment transaction: IAT Entries
A Gateway must provide any corrected data
• the names and complete addresses of all contained within an NOC related to an Inbound
parties to the payment transaction; IAT Entry to the Foreign Gateway within two
banking days of the Settlement Date of the NOC.
• the amount of the payment transaction; and
SUBSECTION 5.1.7  ACH Operator May Not
• the date of the payment transaction. Process Debit Inbound IAT Entries
An ACH Operator acting as a Gateway must not
SUBSECTION 5.1.4  Gateway Must Obtain process debit Inbound IAT Entries, except for
Authorization from ODFI or Gateway’s Customer Reversing Entries.
A Gateway must obtain authorization from either
(i) an ODFI or (ii) a customer of the Gateway SECTION 5.2  Warranties of Gateway
that instructs the Gateway to receive Outbound
IAT Entries on its behalf for re-Transmission to a SUBSECTION 5.2.1  Warranties for Outbound
foreign country to: IAT Entries
A Gateway that Transmits an Outbound IAT Entry
(a) 
Transmit such ODFI’s or customer’s warrants to the ODFI and each ACH Operator
Outbound IAT Entries to a Foreign Gateway; of the Entry that it has edited and processed the
Entry in accordance with the requirements of
(b) arrange for settlement of such Entries with these Rules.
the Foreign Gateway; and
SUBSECTION 5.2.2  Warranties for Inbound
(c) 
arrange for further Transmission of such IAT Entries
Entries to the “foreign RDFI” and settlement A Gateway that Transmits an Inbound IAT Entry
of the amount of such Entries to or from warrants to the RDFI and each ACH Operator of
the “foreign Receiver’s” account. the Entry that it has edited and processed the
Entry in accordance with these Rules.
For purposes of this subsection, the references to
the terms “foreign RDFI” and “foreign Receiver”
are intended to refer to foreign Persons that
SECTION 5.3  Gateway Assumes
perform substantially similar functions as RDFIs Obligations of Other Participants
and Receivers, respectively, and are not intended A Participating DFI acting as a Gateway assumes
to confer any of the rights and responsibilities the specific responsibilities and warranties of
assigned to RDFIs and Receivers under these Rules. an ODFI set forth in Article Two (Rights and
Responsibilities of ODFIs, Their Originators and
SUBSECTION 5.1.5 Gateway Obligation to Third-Party Senders) for each Inbound IAT Entry
Transmit Return Entries for Outbound IAT Entries it processes. Each Participating DFI acting as a
Returned by Foreign Gateway Gateway assumes the specific responsibilities
A Gateway must Transmit a Return Entry for any and warranties of an RDFI set forth in Article
Outbound IAT Entry that is returned to it by the Three (Rights and Responsibilities of RDFIs and
Foreign Gateway in accordance with the foreign Their Receivers) for each Outbound IAT Entry it
law or foreign payment system rules by which the Transmits.
Gateway is bound. The Gateway must Transmit
such a Return Entry in such a time and manner as
to be made available to the ODFI no later than the
opening of business on the second Banking Day
after the Gateway’s receipt of the valid return from
the Foreign Gateway.

2 0 1 3 O P E R AT I N G R U L E S OR49
ARTICLE SIX – Rights and Responsibilities of the National Association

(c) 
to the National Association’s Board of
ARTICLE SIX Directors, committees, employees, agents,
contractors, and Associations in connection
Rights and with a permitted use under Subsection
6.1.1 (Use of Designated Data), provided
Responsibilities that such disclosure is limited to the type,
amount, and elements of Designated Data
of the National that are necessary for such Person(s)
to perform their respective designated
Association functions;

(d) 
to the extent otherwise permitted by
SECTION 6.1  Use and Disclosure applicable Legal Requirements, including
of Designated Data by the National the Federal Right to Financial Privacy Act
Association and Title V of the Gramm-Leach-Bliley
Act, to a financial institution regulatory
SUBSECTION 6.1.1  Use of Designated Data agency with authority with respect to a
The National Association may use Designated Data Participating DFI to which Designated
solely for the following purposes: Data relate;

(a) to monitor ACH quality and compliance (e) 

as required by Legal Requirements,
with these Rules, including for correct including subpoena, or other applicable
use of SEC Codes and formats, and for legal process, subject to compliance with
potential Rules violations or related risks the Federal Right to Financial Privacy Act
to participants in, and users of, the ACH and Title V of the Gramm-Leach-Bliley Act,
system; or to the extent applicable; or,

(b) in support of an enforcement proceeding (f) 

in an aggregate manner that does not
in accordance with Appendix Ten (Rules identify any ACH Operator, Originator,
Enforcement) of these Rules. Receiver, Third-Party Service Provider, or
Participating DFI.
SUBSECTION 6.1.2  Prohibited Use of
Designated Data SUBSECTION 6.1.4  Privacy and Security of
Designated Data
The National Association must not sell Designated
Data or information derived from Designated Data SUBSECTION 6.1.4.1  National Association Must
to any third party and must not use Designated Adopt Data Security Policies
Data for any purpose other than as provided in
The National Association must adopt and
Subsection 6.1.1 (Use of Designated Data).
implement data security policies and procedures
designed to:
SUBSECTION 6.1.3  Disclosure of
Designated Data
(a) ensure the security and confidentiality of
The National Association may disclose Designated Designated Data that are identifiable to a
Data to third parties solely as follows: Participating DFI, Originator, or Receiver;

(a) 
to the ACH Operator from which the (b) 
protect against any anticipated threats
Designated Data were obtained; or hazards to the security or integrity of
Designated Data;
(b) 
to any Participating DFI involved in an
Entry to which Designated Data relate;

OR50 2 0 1 3 O P E R AT I N G R U L E S
 ARTICLE SEVEN – Settlement

(c) protect against unauthorized access to or directly or indirectly from the breach of the
use of Designated Data that could result in National Association’s obligations under Section
substantial harm to any such Participating 6.1 (Use and Disclosure of Designated Data by the
DFI, Originator, or Receiver; and National Association).

(d) ensure the proper disposal of Designated SECTION 6.3  Limitation of Liability
Data.
Notwithstanding any other provision of these
Rules, no ACH Operator or Participating DFI shall
SUBSECTION 6.1.4.2  National Association Must
Comply with Data Breach Policy
have any liability for the acts or omissions of the
National Association, its employees, agents, or
The National Association must comply with
contractors with respect to Designated Data.
the Interim Policy on Data Breach Notification
Requirements, and any revision or replacement
thereof, to the same extent as an ODFI in
possession of Designated Data. ARTICLE SEVEN
SUBSECTION 6.1.4.3  National Association Must Settlement
Comply with Privacy Laws
The National Association must comply with all
applicable Legal Requirements governing the SECTION 7.1  Maintenance of Reserve
confidentiality and security of Designated Data. Bank Accounts
To the extent such Legal Requirements require A Participating DFI must maintain, or have the
the National Association to respond to or provide use through a correspondent of, an account with a
notice to Originators or Receivers about a data Federal Reserve Bank.
security or data privacy breach with respect to
Designated Data in the control of the National
SECTION 7.2  ACH Operators Establish
Association, the National Association is solely
Settlement Procedures
responsible for providing the response or notice,
provided that the National Association coordinates An ACH Operator is responsible for establishing
with the affected Participating DFI. The ACH the procedures under which Entries are settled
Operators have no responsibility or liability with and settlement balances are to be adjusted.
respect to any data security or data privacy breach
related to Designated Data in the control of the SECTION 7.3  Settlement
National Association. An ACH Operator is responsible for effecting
settlement among Participating DFIs for all Entries
SUBSECTION 6.1.5  Other Data Transmitted in accordance with these Rules by
Nothing in this Section 6.1 affects the National crediting and debiting the Participating DFIs’, or
Association’s rights or obligations with respect their designated correspondents’, accounts with
to information or data other than Designated the Federal Reserve Banks. An ACH Operator must
Data it receives in accordance with Section 4.6 effect settlement of Entries in accordance with
(Requirement to Provide Designated Data to these Rules, applicable operating circulars of the
National Association). Federal Reserve Banks, and any other applicable
agreements.
SECTION 6.2  Indemnity by National
Association of ACH Operators SECTION 7.4  Effect of Settlement
The National Association shall indemnify each Settlement of Entries does not preclude a
ACH Operator from and against any and all Participating DFI from pursuing any available
claims, demands, losses, liabilities, and expenses, legal rights or remedies, including any right or
including attorneys’ fees and costs, that result

2 0 1 3 O P E R AT I N G R U L E S OR51
A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

remedy arising out of a Return Entry or Extended for which the RDFI cannot complete settlement.
Return Entry Transmitted after the time frames An ODFI must accept a Return Entry from an ACH
established by these Rules. Operator relating to a Non-Settled Entry and may
not dishonor that Return Entry. The ODFI may not
SECTION 7.5  Accountability for Entries reinitiate a Non-Settled Entry.
An RDFI is accountable for the amount of all debit
SUBSECTION 7.8.2  ACH Operator Must Reverse
Entries received that are not returned in accordance
Entries Received from an ODFI that Cannot Settle
with these Rules, except as provided for in Section
An ACH Operator must create and Transmit to
3.13 (RDFI Right to Transmit Extended Return
the RDFI a Reversing Entry complying with the
Entries), regardless of whether the ODFI complies
requirements of Appendix Three (ACH Record
with the provisions of Subsection 2.12.5 (Dishonor
Format Specifications) for each debit or credit
of Return Entries). This Section 7.5 does not apply
Entry Transmitted to an RDFI for which the ODFI
to Outbound IAT Entries, TRC Entries, and TRX
cannot complete settlement. An RDFI must accept
Entries.
a Reversing Entry from an ACH Operator relating
to a Non-Settled Entry and may not return that
SECTION 7.6  Effect of RDFI Closing on Reversing Entry.
Settlement Date
If the scheduled Settlement Date of a debit Entry
is not a Banking Day for an RDFI but is a day on
which the applicable office of the Federal Reserve
ARTICLE EIGHT
Bank described in Section 7.1 (Maintenance of
Reserve Bank Accounts) is open, settlement will
Definitions of Terms
occur on the scheduled Settlement Date, unless
the RDFI has previously advised the Federal
Used in These Rules
Reserve Bank that settlement for the Entry should
be deferred until the RDFI’s next Banking Day. If
SECTION 8.1  “Accounts Receivable
the RDFI has provided such notice to the Federal
Reserve Bank, settlement for the debit Entry will
Entry” or “ARC Entry” or “ARC”
occur on the RDFI’s next Banking Day, and the a Single Entry debit initiated by an Originator to
RDFI must pay the float charge assessed by the the account of a Receiver based on an Eligible
Federal Reserve Bank. Source Document provided to the Originator by
the Receiver (1) via U.S. mail or delivery service,
SECTION 7.7  Effect of ODFI Closing on (2) at a dropbox location, or (3) in person for
Settlement Date payment of a bill at a manned location.

If the scheduled Settlement Date for a credit Entry

SECTION 8.2  “Acknowledgment Entry”
is not a Banking Day for an ODFI but is a day on
which the applicable office of the Federal Reserve
or “ACK Entry” or “ACK;” or “ATX
Bank described in Section 7.1 (Maintenance of Entry”
Reserve Bank Accounts) is open, settlement will or “ATX”
occur on the scheduled Settlement Date. a Non-Monetary Entry initiated by an RDFI that
provides an acknowledgment of receipt by the
SECTION 7.8  Non-Settled Entries RDFI of a corporate credit payment originated
using the CCD format (“ACK Entry”) or the CTX
SUBSECTION 7.8.1  ACH Operator Must Return format (“ATX Entry”). ACK and ATX Entries must
Entries Originated to an RDFI that Cannot Settle comply with the requirements of Appendix Six
An ACH Operator must create and Transmit to (Acknowledgment Entries).
the ODFI a Return Entry complying with the
requirements of Appendix Four (Return Entries) for
each debit or credit Entry Transmitted to an RDFI

OR52 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

SECTION 8.3  “Addenda Record” SECTION 8.11  “Back Office Conversion

a Record that contains supplemental data related Entry” or “BOC Entry” or “BOC”
to an Entry. a Single Entry debit initiated by an Originator to an
account of a Receiver based on an Eligible Source
SECTION 8.4  “Article 4A” Document provided to the Originator by the
Article 4A of the Uniform Commercial Code as Receiver at the point of purchase or at a manned
enacted in the State of New York. bill payment location for subsequent conversion
during back-office processing.
SECTION 8.5  “Association”
SECTION 8.12  “Banking Day”
a Payment Association, as that term is defined
from time to time in the bylaws of NACHA. with reference to a Participating DFI, any day
on which such Participating DFI is open to the
public during any part of such day for carrying
SECTION 8.6  “Automated Accounting on substantially all of its banking functions, and,
Advice Entry” or “ADV Entry” or “ADV” with reference to an ACH Operator, any day on
a Non-Monetary Entry that is used by an ACH which the applicable facility of such ACH Operator
Operator to provide accounting information is being operated.
regarding an Entry to Participating DFIs in machine
readable format. SECTION 8.13  “Business Day”
a calendar day other than a Saturday, Sunday, or a
SECTION 8.7  “Automated Clearing Federal holiday in the United States.
House” or “ACH”
an Electronic funds transfer system governed by SECTION 8.14  “Check”
these Rules.
a “check” as that term is defined in Article 3 of
the Uniform Commercial Code and includes share
SECTION 8.8  “Automated Clearing drafts.
House Operator” or “ACH Operator”
an entity that acts as a central facility for the SECTION 8.15  “Check Serial Number”
clearing, delivery, and settlement of Entries
the serial number of a Check.
between or among Participating DFIs.

SECTION 8.16  “Check Truncation Entry”

SECTION 8.9  “Automated Enrollment
or “TRC Entry or “TRC;” or “TRX Entry”
Entry” or “ENR Entry” or “ENR”
or “TRX”
a Non-Monetary Entry initiated by a Participating
a debit Entry initiated under a Check Truncation
DFI to an agency of the Federal Government of the
Program. A TRC Entry is for the Truncation of a
United States on behalf, and at the request, of an
single Check drawn on the paying bank. A TRX
account holder at the Participating DFI to enroll in
Entry is for the Truncation of multiple Checks
a service that will enable Entries to such Person’s
drawn on the same paying bank. A TRX Entry may
account at the Participating DFI.
contain up to 9,999 Addenda Records.

SECTION 8.10  “Auxiliary On-Us Field”

SECTION 8.17  “Check Truncation
an optional, variable format field of the MICR line Program”
of a Check of sufficient length. It is positioned
a program for the truncation of Checks based on
to the left of the routing number (or the external
an agreement among two or more Participating
processing code, when such a code is present).
DFIs.
Data located within the Auxiliary On-Us Field is
bracketed by on-us symbols.

2 0 1 3 O P E R AT I N G R U L E S OR53
A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

SECTION 8.18  “Consumer Account” of the Receiver; and (c) data requested by NACHA
to investigate and respond to a specific incident
an account held by a Participating DFI and
involving potential violation of these Rules or risk
established by a natural person primarily for
to Participating DFIs, Originators, or Receivers.
personal, family or household use and not for
The term “Designated Data” does not include
commercial purposes.
the Participating DFI account number, individual
name, and individual identification number fields
SECTION 8.19  “Corporate Credit or of Entry detail Records.
Debit Entry” or “CCD Entry” or “CCD”
a credit Entry, a debit Entry, or a Non-Monetary SECTION 8.25  “Destroyed Check Entry”
Entry originated by an Organization to or from or “XCK Entry” or “XCK”
the account of that Organization or another
a debit Entry initiated with respect to an item
Organization.
described in Subsection 2.5.18.2 (XCK Eligible
Items).
SECTION 8.20  “Corporate Trade
Exchange Entry” or “CTX Entry” or
SECTION 8.26  “Direct Access”
“CTX”
a situation in which an Originator, Third-Party
a credit Entry, debit Entry or Non-Monetary
Sender, or a Third-Party Service Provider Transmits
Entry originated by an Organization to or from
credit or debit Entries directly to an ACH Operator
the account of that Organization or another
using an ODFI’s routing number and settlement
Organization and accompanied by one or more
account.
Addenda Records, up to a maximum of 9,999.

SECTION 8.27  “Direct Access Debit

SECTION 8.21  “Correcting File”
Participant”
a File that corrects the Entries contained in an
an Originator, Third-Party Sender, or Third-
Erroneous File.
Party Service Provider with Direct Access for the
origination of debit Entries except: (a) a Third-
SECTION 8.22  “Customer Initiated Party Service Provider that Transmits Files solely
Entry” or “CIE Entry” or “CIE” on behalf of an ODFI where that Third-Party
a credit Entry initiated by or on behalf of the Service Provider does not have a direct agreement
holder of a Consumer Account to the account of with an Originator (and is not itself an Originator),
a Receiver. or (b) an ODFI that Transmits Files using another
Participating DFI’s routing number and settlement
SECTION 8.23  “Death Notification Entry” account.
or “DNE Entry” or “DNE”
a Non-Monetary Entry that gives notice by an SECTION 8.28  “Direct Financial
agency of the United States Government to an Institution”
RDFI of the death of a Receiver. a Direct Financial Institution, as that term is
defined from time to time in the bylaws of NACHA.
SECTION 8.24  “Designated Data”
the following data regarding Entries, excluding SECTION 8.29  “Electronic”
CIE Entries, processed by an ACH Operator, to the relating to technology having electrical, digital,
extent such ACH Operator agrees to provide such magnetic, wireless, optical, electromagnetic, or
data to the National Association from time to time: similar capabilities.
(a) data derived from Return Entries or Extended
Return Entries, (b) aggregate information from SECTION 8.30  “Electronic Record”
forward Entries that does not permit identification
an agreement, authorization, Written Statement
of Unauthorized Debit, or other Record created,

OR54 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

generated, Transmitted, communicated, received, (k) 

a Check drawn on the Treasury of the
or stored by Electronic means. United States, a Federal Reserve Bank, or a
Federal Home Loan Bank;
SECTION 8.31  “Electronic Signature”
(l) 
a Check drawn on a state or local
an Electronic sound, symbol, or process attached
government that is not payable through or
to or logically associated with an agreement,
at a Participating DFI; or
authorization, Written Statement of Unauthorized
Debit, or other Record and executed or adopted by
(m) a Check payable in a medium other than
a Person with the intent to sign the Record.
United States currency.

SECTION 8.32  “Eligible Source SECTION 8.33  “Entry”

Document”
(a) 
an order or request for the transfer of
a Check that is used as a source of information for money to the deposit account or loan
ARC, BOC or POP Entries. To be used as a source account of a Receiver, or general ledger
of information, the Check must: account of an RDFI (a “credit Entry”);
(a) contain a pre-printed Check serial number; (b) 
an order or request for the withdrawal
of money from the deposit account of a
(b) be in an amount of $25,000 or less;
Receiver, or general ledger account of an
RDFI (a “debit Entry”); and
(c) be completed and signed by the Receiver
(except for POP Entries); and
(c) 
a Non-Monetary Entry to the deposit
account or loan account of a Receiver, or
(d) 
have a routing number, account number
general ledger account of an RDFI.
and Check serial number encoded in
magnetic ink.
An Entry must comply with the requirements
of Appendix Three (ACH Record Format
An Eligible Source Document does not include:
Specifications), Appendix Four (Return Entries),
Appendix Five (Notification of Change), or Appendix
(e) a Check that contains an Auxiliary On-Us
Six (Acknowledgement Entries), as applicable. For
Field in the MICR line;
all Entries except RCK Entries, each debit Entry
shall be deemed an “item” within the meaning of
(f) a Check payable to a Person other than the
Revised Article 4 of the Uniform Commercial Code
Originator;
(1990 Official Text) and that Article shall apply
to such Entries except where the application is
(g) a draft that does not contain the signature
inconsistent with these Rules, in which case these
of the Receiver, including any “remotely
Rules shall control. An RCK Entry is an item as that
created check,” as that term is defined by
term is defined by Revised Article 4 of the Uniform
Regulation CC;
Commercial Code only for the limited purposes
(h) a Check provided by a lender for purposes of presentment as set forth in Article 4-110(c) and
of accessing a credit card account, home notice of dishonor as set forth in Article 4-301(a)(2).
equity line or other form of credit;
SECTION 8.34  “Erroneous Entry”
(i) a Check drawn on an investment company an Entry that (a) is a duplicate of an Entry
as that term is defined in the Investment previously initiated by the Originator or ODFI;
Company Act of 1940; (b) orders payment to or from a Receiver different
than the Receiver intended to be credited or
(j) an obligation of a financial institution (e.g., debited by the Originator; or (c) orders payment
a travelers check, cashier’s check, official in a dollar amount different than was intended by
check, money order, etc.); the Originator.

2 0 1 3 O P E R AT I N G R U L E S OR55
A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

SECTION 8.35  “Erroneous File” point from a country other than the United States
for payment transactions. Also known as a “Foreign
a File that is a duplicate of a previously submitted
Gateway Operator” or “FGO.”
File, or a File in which each Entry, or each Entry in
one or more batches contained in such File, is an
Erroneous Entry. SECTION 8.42  “Gateway”
an ACH Operator or a Participating DFI that acts
SECTION 8.36  “Existing Relationship” as an entry point to or exit point from the United
States for ACH payment transactions. Also known
any point in time that: (a) a written agreement
as a “Gateway Operator” or “GO.”
between an Originator and a Receiver is in effect;
or (b) the Receiver has purchased goods or
services from the Originator within the two-year SECTION 8.43  “Herein”, “Hereinafter”,
period immediately preceding such point in time. “Hereof” or any other similar term
whether capitalized or not, as used in these Rules
SECTION 8.37  “Extended Return Entry” refer to the entire Rules and not to any particular
an Entry initiated by an RDFI in accordance with section or subsection of these Rules.
Section 3.13 (RDFI Right to Transmit Extended
Return Entries) that returns a previously originated SECTION 8.44  “Inbound IAT Entry”
debit Entry to an ODFI. An Extended Return Entry an IAT Entry that originates in a country other
must comply with the requirements of Appendix than the United States and is Transmitted to the
Four (Return Entries). United States.

SECTION 8.38  “File” SECTION 8.45  “Include”, “Including”

a group of Entries associated with a given and other derivatives of those terms
transmittal register and the control totals set forth whether capitalized or not, as used in these Rules
therein. will be interpreted as being followed by the words
“without limitation.”
SECTION 8.39  “Financial Agency”
u SECTION 8.46 “Incomplete Transaction”
an entity that is authorized by applicable Legal
Requirements to accept deposits or to conduct the a payment to an intended third-party payee that
business of issuing money orders or transferring was not made or completed by the Originator,
funds. Third-Party Sender or ODFI of a corresponding
debit Entry authorized by a Receiver for the purpose
SECTION 8.40  “Foreign Correspondent of funding the payment to the third-party payee. A
Bank” partial or erroneous payment to the intended third-
a financial institution or Financial Agency located party payee is not an Incomplete Transaction.
in a country other than the United States that holds
deposits owned by other financial institutions and SECTION 8.47  “International ACH
provides payment and other services to those Transaction” or “IAT Entry” or “IAT”
other financial institutions. an Entry that is part of a payment transaction1
involving a Financial Agency’s office that is not
SECTION 8.41  “Foreign Gateway” located in the territorial jurisdiction of the United
an entity that performs outside of the United States. An office of a Financial Agency is involved
States functions substantially similar to those of in the payment transaction if it (a) holds an account
a Gateway by acting as an entry point to or exit 1
See the NACHA Operating Guidelines chapter on International ACH
Transactions for further guidance on payment transactions.

uApproved April 2, 2012, 2011, Effective March 15, 2013

OR56 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

that is credited or debited as part of the payment SECTION 8.53  “Non-Monetary Entry”
transaction, (b) receives payment directly from a
any notice or data complying with the requirements
Person or makes payment directly to a Person as
of Appendix Three (ACH Record Format
part of the payment transaction, or (c) serves as an
Specifications) that is not an order or request for
intermediary in the settlement of any part of the
the transfer or withdrawal of funds.
payment transaction.
SECTION 8.54  “Non-Settled Entry”
SECTION 8.48  “Internet-Initiated/Mobile
Entry” or “WEB Entry” or “WEB” a credit or debit Entry for which settlement cannot
be completed.
a debit Entry initiated by an Originator to a
Consumer Account of the Receiver based on (1)
an authorization that is communicated, other than
SECTION 8.55  “Notification of Change”
by an oral communication, from the Receiver
or “NOC” or “COR Entry” or “COR”
to the Originator via the Internet or a Wireless a Non-Monetary Entry Transmitted by an RDFI for
Network, or (2) any form of authorization if the purpose of identifying incorrect information
the Receiver’s instruction for the initiation of contained within an Entry and providing correct
the individual debit Entry is designed by the data to be used on future Entries. An NOC is also
Originator to be communicated, other than by known by the SEC Code “COR.” The SEC Code
an oral communication, to the Originator via a “COR” is also used by the ODFI to create a refused
Wireless Network. Notification of Change to refuse an NOC Entry
containing incorrect or incomplete information.
SECTION 8.49  “Legal Requirements” An NOC or refused NOC must comply with the
requirements of Appendix Five (Notification of
any law, statute, rule or regulation, or any
Change).
binding published interpretation of any of the
foregoing, issued by any government authority
(including courts), and any judicial, governmental,
SECTION 8.56  “Organization”
or administrative order, judgment, decree or a corporation, partnership, association or other
ruling, in each case as applicable to the subject entity, governmental or private, or a natural person,
matter and the parties at issue, and as amended, provided that, in the case of a natural person,
supplemented, modified or replaced from time to any account of such natural person to be debited
time. or credited in respect of an Entry is maintained
primarily for commercial and not for personal,
SECTION 8.50  “Machine Transfer Entry” family or household purposes.
or “MTE Entry” or “MTE”
a credit or debit Entry initiated at an “electronic
SECTION 8.57  “Originating Automated
terminal,” as that term is defined in Regulation E,
Clearing House Operator” or
to a Consumer Account maintained with an RDFI, “Originating ACH Operator”
i.e., an ATM cash deposit or withdrawal. an ACH Operator that receives Entries from an
ODFI with which it has an agreement. In the
SECTION 8.51  “MICR” event Entries are Transmitted between an ODFI
and an RDFI through a single ACH Operator, the
a magnetic ink character recognition technology
term refers to that ACH Operator.
adopted to facilitate the processing of Checks.

SECTION 8.58  “Originating Depository

SECTION 8.52  “National Association”
Financial Institution” or “ODFI”
or “NACHA”
a Participating Depository Financial Institution
the National Automated Clearing House
with respect to Entries (a) it Transmits directly
Association.
or indirectly to an ACH Operator for Transmittal

2 0 1 3 O P E R AT I N G R U L E S OR57
A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

to an RDFI, and (b) on which it is designated as Source Document provided to the Originator by
the ODFI in accordance with Appendix Three the Receiver at the point-of-purchase or manned
(ACH Record Format Specifications). An RDFI bill payment location.
is not considered an ODFI solely by reason of
its initiation of Acknowledgment Entries, Return SECTION 8.65  “Point of Sale Entry” or
Entries, Extended Return Entries, or Notifications “POS Entry or “POS”
of Change.
a debit Entry initiated at an “electronic terminal,” as
that term is defined in Regulation E, to a Consumer
SECTION 8.59  “Origination Agreement” Account of the Receiver to pay an obligation
a written agreement between an ODFI and an incurred in a point-of-sale transaction, or to effect
Originator or Third-Party Sender (on behalf of a point-of-sale terminal cash withdrawal. Also an
an Originator with which the Third-Party Sender adjusting or other credit Entry related to such debit
has an agreement) that authorizes the ODFI to Entry, transfer of funds, or obligation.
Transmit Entries to a Receiver’s account and that
meets all other applicable requirements set forth in SECTION 8.66  “Prearranged Payment
Subsection 2.2.1.1 (ODFI Must Enter Origination and Deposit Entry” or “PPD Entry” or
Agreement with Originator) and/or Subsection “PPD”
2.2.1.2 (ODFI Must Enter Origination Agreement
with Third-Party Sender). a credit or debit Entry initiated by an Organization
to a Consumer Account of a Receiver based on a
standing or a Single Entry authorization from the
SECTION 8.60  “Originator” Receiver.
a Person that has authorized an ODFI (directly or
through a Third Party Sender) to Transmit, for the SECTION 8.67  “Prenotification Entry” or
account of that Person, a credit Entry, debit Entry, “Prenotification” or “Prenote”
or Non-Monetary Entry to the Receiver’s account
at the RDFI. a Non-Monetary Entry initiated by an Originator
to an RDFI prior to the initiation of the first credit
or debit Entry to a Receiver’s account with the
SECTION 8.61  “Outbound IAT Entry”
RDFI. A Prenotification notifies the RDFI that the
an IAT Entry that originates in the United States Originator intends to initiate one or more credit or
and is Transmitted to another country. debit Entries to a Receiver’s account with that RDFI
in accordance with the Receiver’s authorization.
SECTION 8.62  “Participating Depository
Financial Institution” or “Participating SECTION 8.68  “Re-presented Check
DFI” Entry” or “RCK Entry” or “RCK”
a financial institution that (a) is authorized by a Single Entry debit constituting a presentment
applicable Legal Requirements to accept deposits, notice of an item eligible under Subsection
(b) has been assigned a routing number by Accuity, 2.5.13.3 (RCK Eligible Items). An RCK Entry is an
and (c) has agreed to be bound by these Rules. item as that term is defined by Revised Article 4 of
the Uniform Commercial Code (1990 Official Text)
SECTION 8.63  “Person” only for the limited purposes of presentment as set
a natural person or an Organization. forth in Article 4-110(c) and notice of dishonor as
set forth in Article 4-301(a)(2).
SECTION 8.64  “Point-of-Purchase
Entry” or “POP Entry” or “POP” SECTION 8.69  “Receiver”
a Person that has authorized an Originator to
a Single Entry debit initiated by an Originator to
initiate a credit Entry, debit Entry, or Non-Monetary
an account of the Receiver based on an Eligible
Entry to the Receiver’s account at the RDFI. With
respect to debit Entries, the term “Receiver”

OR58 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

means all Persons whose signatures are required Funds Availability Act (12 U.S.C §§ 4001-4010) and
to withdraw funds from an account for purposes the Check Clearing for the 21st Century Act (12
of the warranty provisions of Subsection 2.4.1 U.S.C §§ 5001-5018).
(General ODFI Warranties).
SECTION 8.76  “Regulation D”
SECTION 8.70  “Receiving Automated the regulations adopted by the Board of Governors
Clearing House Operator” or “Receiving of the Federal Reserve System at 12 C.F.R. Part 204
ACH Operator” from time to time to implement certain sections
an ACH Operator that distributes Entries to an of the Federal Reserve Act, including Section 19
RDFI with which it has an agreement. In the event thereof, (12 U.S.C. § 3105 et seq.) and Section 7 of
Entries are Transmitted between an ODFI and an the International Banking Act of 1978 (12 U.S.C.
RDFI through a single ACH Operator, the term § 3105 et seq.).
refers to that ACH Operator.
SECTION 8.77  “Regulation E”
SECTION 8.71  “Receiving Depository the regulations adopted by the Board of Governors
Financial Institution” or “RDFI” of the Federal Reserve System at 12 C.F.R. Part 205
a Participating Depository Financial Institution from time to time to implement the Electronic
with respect to Entries (a) it receives from its ACH Fund Transfer Act (15 U.S.C. §§ 1693 et seq.).
Operator to the accounts of Receivers, and (b) on
which it is designated as the RDFI in accordance SECTION 8.78 “Reject”
with Appendix Two (ACH Record Format the return of a failed Entry or Return Entry by
Specifications). An ODFI is not considered an RDFI an ACH Operator to another ACH Operator, an
solely by reason of its receipt of Acknowledgement ODFI (or its Transmitting Point), or an RDFI (or its
Entries, Return Entries, Extended Return Entries, Receiving Point).
or Notifications of Change.
SECTION 8.79  “Return Entry” or
SECTION 8.72  “Receiving Point” “Return”
an Organization that receives Entries from an ACH a credit or debit Entry initiated by an RDFI or
Operator on behalf of an RDFI. A Receiving Point ACH Operator, that returns a previously originated
may be an RDFI acting on its own behalf, or a credit or debit Entry, to the ODFI within the time
Participating DFI or Third-Party Service Provider frames established by these Rules. A Return Entry
acting on behalf of one or more RDFIs. must comply with the requirements of Appendix
Four (Return Entries). For all Entries except IAT
SECTION 8.73  “Reclamation Entry” Entries, an ODFI may dishonor a Return Entry.
a debit Entry initiated by an Originator to reclaim A dishonored Return Entry must comply with
from an RDFI any amounts received by a Recipient Subsection 2.12.5 (Dishonor of Return Entries)
after death or legal incapacity or the death of a and Appendix Four (Return Entries). For all
beneficiary of the Recipient. Entries except IAT Entries, an RDFI may create a
corrected or contested dishonored Return Entry
SECTION 8.74  “Record” in compliance with Subsection 3.8.5 (Receipt of
Dishonored Returns) and Appendix Four (Return
information that is inscribed on a tangible medium
Entries).
or that is stored in an Electronic or other medium
and is retrievable in perceivable form.
SECTION 8.80 “Return Fee”
SECTION 8.75  “Regulation CC” A fee charged by an Originator to a Receiver for
a debit Entry or other item that was returned for
the regulations adopted by the Board of Governors
insufficient or uncollected funds, to the extent
of the Federal Reserve System at 12 C.F.R. Part 229
permitted by applicable Legal Requirements.
from time to time to implement the Expedited

2 0 1 3 O P E R AT I N G R U L E S OR59
A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

SECTION 8.81 “Return Fee Entry” SECTION 8.88  “Single Entry”

A Single Entry initiated by an Originator to the a credit or debit Entry initiated by an Originator in
account of a Receiver to collect a Return Fee. accordance with the Receiver’s authorization for a
one-time transfer of funds to or from the Receiver’s
SECTION 8.82  “Reversing Entry” account.
or “Reversal”
a credit or debit Entry that reverses an Erroneous SECTION 8.89  “Standard Entry Class
Entry. Code” or “SEC Code”
a three-character code that identifies the type of
SECTION 8.83“Reversing File” Entry.
a File that reverses all Entries in an Erroneous File.
SECTION 8.90  “Telephone-Initiated
SECTION 8.84  “Rules” or “NACHA Entry” or “TEL Entry” or “TEL”
Operating Rules” or “NACHA Rules” or a debit Entry initiated by an Originator to a
“ACH Rules” Consumer Account of the Receiver based on an
oral authorization obtained over the telephone.
the Operating Rules of the National Automated
Clearing House Association, including all
appendices, formal rules interpretations, and SECTION 8.91  “Third-Party Sender”
schedule of fees, as in effect from time to time. an Organization that is not an Originator that
has authorized an ODFI or a Third Party Service
SECTION 8.85  “Sending Point” Provider to Transmit, for its account or the account
of another Third-Party Sender, a credit Entry, debit
an Organization that Transmits Entries to an ACH
Entry, or Non-Monetary Entry to the Receiver’s
Operator on behalf of an ODFI. A Sending Point
account at the RDFI. An Organization acting as
may be an ODFI acting on its own behalf, or a
Third-Party Sender also is a Third-Party Service
Participating DFI or Third-Party Service Provider
Provider.
acting on behalf of one or more ODFIs.

SECTION 8.92  “Third-Party Service

SECTION 8.86  “Settlement Date”
Provider”
with respect to a credit or debit Entry, the date
an Organization that performs any functions on
an exchange of funds with respect to an Entry
behalf of the Originator, the ODFI, or the RDFI
is reflected on the books of the applicable
(not including the Originator, ODFI or RDFI acting
Federal Reserve Bank(s), and with respect to
in such capacity for such Entries) related to the
a Non-Monetary Entry, the date specified in the
processing of Entries, including the creation of the
“Settlement Date” field of the Entry.
Files or acting as a Sending Point or Receiving Point
on behalf of a Participating DFI. An Organization
SECTION 8.87  “Shared Network Entry” acting as Third-Party Sender also is a Third-Party
or “SHR Entry” or “SHR” Service Provider.
a debit Entry initiated at an “electronic terminal,” as
that term is defined in Regulation E, to a Consumer SECTION 8.93  “Transaction Account”
Account of the Receiver to pay an obligation
a “transaction account” as that term is defined in
incurred in a point-of-sale transaction, or to effect
Regulation D.
a point-of-sale terminal cash withdrawal. Also
an adjusting or other credit Entry related to such
debit Entry, transfer of funds, or obligation. SHR SECTION 8.94  “Transmit”
Entries are initiated in a shared network where the to send by Electronic means of communication.
ODFI and RDFI have an agreement in addition to
these Rules to process such Entries.

OR60 2 0 1 3 O P E R AT I N G R U L E S
 A R T I C L E E I G H T – D e f i n i t i o n s o f Te r m s U s e d i n T h e s e R u l e s

SECTION 8.95  “Truncation”

a process whereby Checks are presented by
Transmission of information describing the Check
rather than by the delivery of the Check itself.

SECTION 8.96  “Uniform Commercial

Code” or “UCC”
the Uniform Commercial Code as enacted in the
State of New York, unless otherwise provided.

SECTION 8.97  “Unsecured Electronic

Network”
a network, public or private, that (1) is not located
entirely within a single, contiguous, physical facility,
and (2) either (a) Transmits data via circuits that
are not dedicated to communication between two
end-points for the duration of the communication,
or (b) Transmits data via wireless technology
(excluding a communication that begins and ends
with a wireline connection, but that is routed by a
telecommunications provider for a portion of the
connection over a wireless system). For clarity, the
Internet is an Unsecured Electronic Network, even
though secure transmissions may be made over
that otherwise unsecure network.

SECTION 8.98  “Wireless Network”

an Unsecured Electronic Network for the
communication of data using wireless technology.

SECTION 8.99  “Written Statement of

Unauthorized Debit”
a written notice submitted by a Receiver to an
RDFI requesting recredit to the Receiver’s account
with the RDFI for debit to the Receiver’s account
that was not authorized by the Receiver or was
improper, as provided in Section 3.12 (Written
Statement of Unauthorized Debit).

u a written notice submitted to an RDFI by a Receiver

requesting recredit to the Receiver’s account with
the RDFI for a debit to the Receiver’s account that
was not authorized by the Receiver, was improper,
or was part of an Incomplete Transaction, as
provided in Section 3.12 (Written Statement of
Unauthorized Debit).

uApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR61
APPENDIX ONE – ACH File Exchange Specifications

• all alphabetic characters within the Change

Code and Refused COR Code fields;
APPENDIX ONE
ACH File Exchange • all alphabetic characters within the Return
Reason Code, Dishonored Return Reason
Specifications Code, and Contested Dishonored Return
Reason Code fields;

• Company Entry Description fields containing

The following information outlines the requirements
the words “REVERSAL,” “RETURN FEE,”
for processing Electronic transmissions, addresses
“RECLAIM,” “NONSETTLED,” “AUTOENROLL”
the sequence of Records in an ACH File, and gives
(for ENR entries), “REDEPCHECK” (for RCK
a descriptive overview of the various records
entries), and “NO CHECK” (for XCK entries);
contained in a File.
and

PART 1.1  Electronic Transmission • Company Name fields containing the words
Requirements “CHECK DESTROYED” (for XCK entries).
A Participating DFI and its ACH Operator need to
address operating details (testing, implementation PART 1.3  Sequence of Records in
and contingency plans) to ensure compatibility in ACH Files
Electronic File Transmission.
Each ACH File begins with a File Header Record.
After the File Header Record may be any number
PART 1.2  Data Specifications for of batches. Each batch is identified by a Company/
ACH Records Batch Header Record and contains one or more
The following table shows the data specifications Entry Detail Records. The number of addenda
for ACH Records. records that accompany each Entry is dependent
upon the Standard Entry Class Code. At the end
of each batch is a Company/Batch Control Record.
TYPE OF ALPHABETIC/ Each File ends with a File Control Record.
NUMERIC
FIELD ALPHAMERIC
0-9, A-Z, a-z, space,
EBCDIC values greater
The records in ACH files must be in the following
Valid
than hexadecimal “3F”, 0-9 sequence:
Characters
ASCII values greater than
hexadecimal “1F”
File Header Record
Justification Left Right
Batch #1
Empty Field
Handling
Space filled Zero filled Company/Batch Header Record

Special
Certain fields require the use Must be unsigned Entry Detail Records or Corporate Entry
of UPPER CASE characters (Neither positive (+) or
Notes Detail Records (with/without optional
– see below. negative (–) signage.)
Addenda Records)
Company/Batch Control Record
UPPER CASE characters must be used for all of the
following: Batch #2
Company/Batch Header Record
• all alphabetic characters within the Standard
Entry Class Code field; Entry Detail Records or Corporate Entry
Detail Records (with/without optional
• all alphabetic characters within the File ID Addenda Records)
Modifier field; Company/Batch Control Record

OR62 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX ONE – ACH File Exchange Specifications

Batch #n participants in the transaction. The information in

the Company/Batch Header Record identifies the
Company/Batch Header Record
Originator; the Trace Number identifies the ODFI;
Entry Detail Records or Corporate Entry DFI routing and account information identifies both
Detail Records (with/without optional the RDFI and the specific account. In addition to
Addenda Records) the basic Entry format, Transaction Codes for Entry
Detail Records have been defined to accommodate
Company/Batch Control Record
Prenotification records, zero dollar CCD, CTX, and
File Control Record IAT Entries, and Return Entries.

Any other sequence will cause the File to be Prenotifications are identical to the basic Entry
rejected (see diagrams on the following pages). format but contain appropriate Transaction Codes
and zeros in the Amount field. Prenotifications
PART 1.4  File Structure can be batched with other dollar entries or batched
separately.
File Header Record
The File Header Record designates File Zero dollar CCD, CTX, and IAT Entries are identical
characteristics and identifies the immediate origin to the basic Entry format but contain appropriate
(Sending Point or ACH Operator) and destination Transaction Codes and zeros in the Amount field.
(Receiving Point or ACH Operator) of the Entries Zero dollar CCD, CTX, and IAT Entries can be
contained within the File or within the Transmitted batched with other CCD, CTX, and IAT dollar
batched data. In addition, this Record includes Entries or batched separately. A zero dollar CCD,
date, time, and File identification fields, which can CTX Entry must be accompanied by at least one
be used to identify the File uniquely. Addenda Record. A zero dollar IAT Entry must
be accompanied by at least the seven mandatory
Company/Batch Header Record Addenda Records.
The Company/Batch Header Record identifies
Return Entries are distinguished by special
the Originator and briefly describes the purpose
Transaction Codes and must be batched separately
of the Entry. For example, “Gas Bill” or “REG
from other dollar entries.
SALARY” indicates the reason for the transaction
originated by the Originator. The Company/Batch
Addenda Records
Header Record contains the routing number of the
ODFI for settlement, routing of Returns, and other Originators can use Addenda Records to supply
control purposes. In addition, the Company/Batch additional information about Entry Detail Records
Header Record indicates the intended Effective that will pass from the ODFI through the ACH
Entry Date of all transactions within the batch. Operator to the RDFI. Addenda Records associated
The information contained in the Company/Batch with the original Entry Detail Record or Corporate
Header Record applies uniformly to all subsequent Entry Detail Record are not included with any
Entry Detail Records in the batch. Entry Detail Record being returned, with the
exception of IAT Entries. Only NACHA sanctioned
Entry Detail Record/Corporate Entry Detail formats are permitted, as specified by the Addenda
Record Type Code. Addenda Record information may only
be used for the purpose of Transmitting payment
Entry Detail Records contain that information
related information. Any other use is prohibited.
sufficient to relate the Entry to the Receiver,
Each application, with its corresponding number
i.e., Receiver’s account number at the RDFI,
of addenda records, is listed in the chart on the
identification number, name, amount, and debit or
following page.
credit, as indicated by the Transaction Code.

The information in the Company/Batch Header

Record must be incorporated with the Entry
Detail Record to fully describe the Entry and all

2 0 1 3 O P E R AT I N G R U L E S OR63
APPENDIX ONE – ACH File Exchange Specifications

MAXIMUM NUMBER
OPTIONAL/
SEC CODE CONTENTS REFERENCE ADDENDA
MANDATORY
RECORDS
ANSI ASC X12 REF (Reference) Appendix Six, Subpart 6.4.2; Optional
ACK 1
data segment Appendix Three, Subpart 3.2.2

ADV N/A N/A 0 N/A

ARC N/A N/A 0 N/A

ANSI ASC X12 REF (Reference) Appendix Six, Subpart 6.4.3; Optional
ATX 1
data segment Appendix Three, Subpart 3.2.2

BOC N/A N/A 0 N/A

Payment Related ANSI ASC Appendix Three, Subpart 3.1.8,

Optional
CCD, PPD X12 data segments, NACHA Subpart 3.1.17, and Subpart 1
endorsed banking convention 3.2.2

Payment Related ANSI ASC X12 Appendix Three, Subpart 3.1.9 Optional
CIE 1
data segments and Subpart 3.2.2

COR/Refused COR
Appendix Five, Part 5.4;
(Notification of Corrected Data 1 Mandatory
Appendix Three, Subpart 3.2.2
Change)
ANSI ASC X12.5 or X12.6
syntax, an ASC X12 transaction
Appendix Three, Subpart 3.1.10 Optional
CTX set containing a BPR or BPS 9,999
and Subpart 3.2.2
data segment, or payment
related UN/EDIFACT syntax

NACHA endorsed banking Appendix Three, Subpart 3.1.11

DNE 1 Mandatory
convention and Subpart 3.2.2

NACHA endorsed banking Appendix Three, Subpart 3.1.12

ENR 9,999 Mandatory
convention and Subpart 3.2.2

Parties to the transaction;

Appendix Three, Subpart 3.1.13 Mandatory (7)
IAT payment related remittance 12
and Subpart 3.2.2 Optional (5)
information

POP N/A N/A 0 N/A

Appendix Three, Subpart 3.1.16,

Terminal and card transaction
POS, SHR, MTE Subpart 3.1.14, Subpart 3.1.19, 1 Mandatory
information
and Subpart 3.2.2

RCK N/A N/A 0 N/A

Returns, Dishonored Appendix Four, Part 4.3, Part

Returns, Contested Return entry data 4.4, Part 4.5; Appendix Three, 1 Mandatory
Dishonored Returns Subpart 3.2.2

TEL N/A N/A 0 N/A

TRC N/A N/A 0 N/A

National Association for Check Appendix Three, Subpart 3.1.22

TRX 9,999 Mandatory
Safekeeping syntax and Subpart 3.2.2

Payment related ANSI ASC

Appendix Three, Subpart 3.1.23
WEB X12 data segments, NACHA 1 Optional
and Subpart 3.2.2
endorsed banking convention

XCK N/A N/A 0 N/A

OR64 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX ONE – ACH File Exchange Specifications

Company/Batch Control Record the number of batches within the File (or batched
The Company/Batch Control Record contains the data Transmitted to a single destination).
counts, hash totals, and total dollar controls for the
preceding Entries within the batch. PART 1.5  Trace Number Sequence in
ACH Files
All Entry Detail Records are hashed. Both Entry Individual Entry Detail Records within individual
Detail Records and Addenda Records are included batches must be in ascending Trace Number order
in the Entry/addenda counts; Batch Header and (although Trace Numbers need not necessarily be
Batch Control Records are not included. consecutive). The Trace Number in an Addenda
Record is the same as that of the Entry Detail Record
File Control Record with which the Addenda Record is associated.
The File Control Record contains dollar, Entry,
and hash total accumulations from the Company/ Addenda Records must be in consecutive ascending
Batch Control Records in the File. This Record order by the Addenda Sequence Number.
also contains counts of the number of blocks and

2 0 1 3 O P E R AT I N G R U L E S OR65
APPENDIX ONE – ACH File Exchange Specifications

DIAGRAM OF SEQUENCE OF RECORDS FOR ACK, ARC, ATX, BOC, CCD, COR, CIE,
DNE, MTE, POP, POS, PPD, RCK, SHR, TEL, AND WEB ENTRIES

First physical record(s) on file

File Transmission Record

File Header Record One per file — first logical record on file

Company/Batch One per batch

Header Record

}
First Entry Each entry detail may have an optional
Detail Record Addenda record

Second Entry
Detail Record
• Batch 1
•
•
Last Entry
Detail Record

Company/Batch
One per batch
Control Record
•
•
Batches 2 through n-1
•
Company/Batch

}
Header Record

First Entry
Detail Record
•
• Batch n
•
Last Entry
Detail Record

Company/Batch
Control Record

File Control Record One per file — last logical record

File used to complete last physical block

9999....99999

OR66 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX ONE – ACH File Exchange Specifications

DIAGRAM OF SEQUENCE OF RECORDS FOR

CTX, ENR, IAT AND TRX ENTRIES

File Transmission Record

File Header Record

Company/Batch
Header Record
First (Corporate) Entry Detail
Record
Addenda Record
#1
Addenda Record
#2
Addenda Record
#3
Addenda Record
#n
Second (Corporate) Entry Detail
Record
Addenda Record
#1
Addenda Record
#2

Company/Batch Control Record

Batches 2 through n

File Control Record

9999....99999

2 0 1 3 O P E R AT I N G R U L E S OR67
APPENDIX TWO – Specifications for Data Acceptance by ACH Operators

j. Originating DFI Identification

APPENDIX TWO k. Originating DFI Name (if available)

Specifications for l. Company Name

m. Company Identification
Data Acceptance by n. Batch Number

ACH Operators o. Effective Entry Date

p. Batch Entry/Addenda Count
q. Total Debit Dollar Amount
The data acceptance criteria below apply to Entries
Transmitted by Sending Points or ACH Operators. r. Total Credit Dollar Amount
The ACH Operator will reject a File, batch, or Entry s. Reason for Batch Rejection.
that does not comply with these specifications.
PART 2.2  Originator Status Code Review
PART 2.1  File Acknowledgment
Each Originating ACH Operator reviews each batch
Each Originating ACH Operator generates an of Entries it receives to ensure that the appropriate
acknowledgment for every File Transmitted for status code pertaining to the Originator (the
processing. The acknowledgment is in the form of “Originator Status Code”) is included in accordance
a message or report transmitted or made available with Appendix Three (ACH Record Format
to the Sending Point electronically. The ACH Specifications). If a batch of Entries contains an
Operator makes the acknowledgment available incorrect Originator Status Code or contains no
as soon as possible after the completion of the Originator Status Code, the ACH Operator either
edits listed in Parts 2.3 (Automatic File Rejection rejects the batch or inserts the correct Originator
Criteria), 2.4 (Automatic Batch or File Rejection Status Code.
Criteria), and 2.5 (Automatic Entry Detail Rejection
Criteria) of this Appendix Two. At a minimum, PART 2.3  Automatic File Rejection
the acknowledgment includes information from
Criteria
the following fields within the Sending Point’s File
Header and File Control Records: The ACH Operator will always reject the entire File
if any of the following error conditions exists:
a. Immediate Origin
• The File cannot be successfully read, e.g.,
b. Immediate Origin Name (if available) data read failures, improper block size,
c. File Creation Date presence of invalid header labels, hardware/
software error checks indicated.
d. File Creation Time (if available)
e. File ID Modifier • The File contains any “undefined” record
f. File Entry/Addenda Count type.

g. Total Debit Entry Dollar Amount in File • The File Header Record does not contain
h. Total Credit Entry Dollar Amount in File the number of a valid Sending Point or ACH
Operator (as defined on the ACH Operator
i. File Batch Count.
routing table file).
The acknowledgment also contains the date and
• The File is “out-of-balance,” i.e., one or more
time the File was processed by the ACH Operator
of the following conditions exist:
and, if the File was rejected, the reason for the
rejection. If the File was not rejected, but one or
– the summation of the counts, hash totals,
more batches were rejected by the ACH Operator,
and total dollars on Company/Batch
the acknowledgment will also contain the following
Control Records does not agree with the
information about each rejected batch:
File Control Record.

OR68 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TWO – Specifications for Data Acceptance by ACH Operators

– the actual number of blocks or batches in • The Trace Numbers on the File are not in
the File does not agree with the File Control ascending sequence within a batch.
Record counts.
• The Transaction Code in an Entry Detail
• Mandatory fields in the File Header Record Record is invalid.
are not valid:
• The ODFI of a TRC/TRX batch is not a
– File ID Modifier is not uppercase A-Z or participant in a check truncation program.
0-9.
• The Amount field in an Entry Detail Record is
– Record size is not 094.
non-numeric.
– Blocking Factor is not 10.
– Format Code is not 1. • The sequence of records in the batch is
incorrect.
• The sequence of records in the File is
incorrect. • The batch is “out-of-balance,” i.e., the counts,
hash totals, or dollars in the Company/
• The Immediate Origin, File Creation Date, Batch Control Records do not agree with the
File Creation Time, and File ID Modifier are summation of the Entries for the batch.
equal to that of a previously accepted file.
• The Company Name is all spaces or all zeros.
PART 2.4  Automatic Batch or File • The Company Entry Description is all spaces
Rejection Criteria or all zeros.
A Sending Point must choose either a batch level
reject option or a File level reject option for any • The Company Identification is all spaces or
batch(es) within the File that meets one or more of all zeros.
the error conditions defined below. If the Sending
Point chooses the File level reject option, the ACH • The Originator Status Code is not equal to “2”
Operator will reject the entire File containing the for DNE if the Transaction Code is 23 or 33.
erroneous batch(es). If the Sending Point chooses
the batch level reject option, those specific batches • The Standard Entry Class Code in the
with an erroneous condition will be rejected, but Company/Batch Header Record is not a valid
the remaining batches within the File will be code.
accepted and processed by the ACH Operator.
• The Service Class Code in the Company/
The ACH Operator will reject a batch or the entire Batch Control Record is not the same as that
File, depending on the reject option selected, if any in the Company/Batch Header Record.
batch meets any of the following error conditions:
• The first eight positions of the Trace
• The batch contains invalid characters (i.e., Number in an Entry Detail Record are not
characters not specified in Appendix One, the same as the ODFI Routing Number in
ACH File Exchange Specifications). the corresponding (immediately preceding)
Company/Batch Header Record.
• Except for Files coming from another ACH
Operator, the ODFI Identification in the • The Transaction Code in an Entry Detail
Company/Batch Header Record is not the Record is not valid for the Service Class
routing number of a valid ODFI. Code in the Company/Batch Header Record.
Either a debit Transaction Code is in a credit
• The Service Class Code in a Company/Batch batch, or a credit Transaction Code is in a
Header Record is not a valid code. debit batch.

2 0 1 3 O P E R AT I N G R U L E S OR69
APPENDIX TWO – Specifications for Data Acceptance by ACH Operators

• The Transaction Code in an Entry Detail PART 2.5  Automatic Entry Detail
Record is not valid for the Standard Entry Rejection Criteria
Class Code in the Company/Batch Header
ACH Operators use Return Reason Codes for the
Record. For Standard Entry Class Code COR,
following error conditions. These error conditions
the Transaction Code must be 21, 26, 31, 36,
will never cause the entire File or batch to be
41, 46, 51, or 56. For Standard Entry Class
rejected but will always cause the Entry Detail
Code DNE, the Transaction Code must be 21,
Record to be returned using an Addenda Record
23, 31, or 33.
with an Addenda Type Code of “99.” Return Entries
must comply with the requirements of Appendix
•  Forward Entries and Return Entries are in
Four (Return Entries).
the same batch.
R13  Invalid ACH Routing Number
• Return, dishonored Return, and/or contested
dishonored Return Entries are in the same
• Entry contains a Receiving DFI Identification
batch.
or GO Identification that is not a valid ACH
routing number.
• The Batch Number in the Company/Batch
Header Record is non-numeric.
R18  Improper Effective Entry Date
• The Batch Number in the Company/Batch
• The Effective Entry Date for a credit Entry
Control Record is non-numeric.
is more than two Banking Days after the
Banking Day of processing as established by
• The Batch Number in the Company/Batch
the Originating ACH Operator.
Control Record is not the same as the Batch
Number in the Company/Batch Header
• The Effective Entry Date for a debit entry
Record.
is more than one Banking Day after the
processing date.
• The Foreign Exchange Indicator is all spaces
or all zeros (IAT Entries).
R19  Amount Field Error
• The ISO Destination Country Code is all
• Amount field is non-numeric.
spaces or all zeros (IAT Entries).
• Amount field is not zero in a Prenotification,
• The Originator Identification is all spaces or
DNE, ENR, Notification of Change, refused
all zeros (IAT Entries).
Notification of Change, or zero dollar Entry.
• The ISO Originating Currency Code is all
• Amount field is zero in an Entry other than
spaces or all zeros (IAT Entries).
a Prenotification, DNE, ENR, Notification
of Change, refused Notification of Change,
• The ISO Destination Currency Code is all
Return, dishonored Return, contested
spaces or all zeros (IAT Entries).
dishonored Return, or zero dollar Entry.
• The GO Identification/Originating DFI
• Amount field is greater than $25,000 for ARC,
Identification in the Company/Batch Header
BOC, and POP Entries.
Record is not the routing number of a valid
Gateway Operator or ODFI (IAT Entries).
R25  Addenda Error

• Addenda Record Indicator value is not 0

or 1.

• Addenda Record Indicator value is 0 but

Addenda Record follows.

OR70 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TWO – Specifications for Data Acceptance by ACH Operators

• Addenda Record Indicator value is 1 but no • Total number of Addenda Records exceeds
Addenda Record follows. the maximum number allowable (9,999) per
Entry Detail Record (CTX, ENR, or TRX).
• Addenda Record Indicator on a CTX, ENR,
IAT, or TRX Entry is 0 and Number of • Total number of Addenda Records exceeds
Addenda Records is not zero. Addenda the maximum allowable (12) per Entry Detail
Record Indicator is 1 and Number of Addenda Record (IAT).
Records is 0.
• The number of Addenda Records exceeds
• The Addenda Record Indicator for one (1) for CCD, CIE, DNE, MTE, POS, PPD,
Notifications of Change, refused Notifications SHR, WEB, Notifications of Change, refused
of Change, Returns, dishonored Returns, Notifications of Change, Returns, dishonored
contested dishonored Returns, DNE, ENR, Returns, and contested dishonored Returns.
MTE, POS, SHR, TRX, and zero dollar Entries
other than Prenotifications is not equal to • Addenda Sequence Number is not valid.
“1.” The Addenda Record Indicator for IAT
Entries, including Prenotification Entries, is • The actual number of Addenda Records is
not equal to “1.” not equal to the number of Addenda Records
in the Corporate Entry Detail Record (CTX)
• Addenda Type Code is not valid if not equal or the Entry Detail Record (ENR, IAT, TRX).
to “02” for MTE, POS, or SHR Entries; “05” for
ACK, ATX, CCD, CIE, CTX, DNE, ENR, PPD, • For IAT forward Entries and IAT Returns,
TRX, or WEB Entries; “98” on Notification of the Entry Detail Sequence Number does
Change or refused Notification of Change; not correspond to the Trace Number on the
or “99” on Return, dishonored Return, or preceding IAT Entry Detail Record.
contested dishonored Return Entries.
R26  Mandatory Field Error
• For IAT Entries, Addenda Type Code is not
valid if not equal to “10,” “11,” “12,” “13,” “14,” • Individual Name contains all spaces or all
“15,” “16,” “17,” or “18.” Addenda Type Code zeros (MTE, TEL, and WEB Entries).
for an IAT Return is not valid if not equal to
“10,” “11,” “12,” “13,” “14,” “15,” “16,” or “99.” • For IAT Entries, any mandatory field contains
Addenda Type Code for an IAT Notification all spaces or all zeros.
of Change is not valid if not equal to “98.”
• Individual Identification Number contains
• For IAT forward Entries and IAT Returns, all spaces or all zeros (MTE Entries or CIE
Addenda Type Codes 10-16 are not in Entries).
appropriate sequential order.
• Check Serial Number contains all spaces
• One or more mandatory Addenda Records or all zeros (ARC, BOC, POP, RCK, or XCK
for IAT forward Entries, Returns, and Entries).
Notifications of Change is missing.
• Terminal City contains all spaces or all zeros
• For IAT forward Entries and IAT Returns, the (POP Entries only).
Entry contains more than one of each of the
following Addenda Types: “10,” “11,” “12,” • Terminal State contains all spaces or all zeros
“13,” “14,” “15,” and “16.” (POP Entries only).

• For IAT forward Entries, the Entry contains • Card Transaction Type Code is not a valid
more than two Addenda Records for code as specified in Appendix Three (ACH
Remittance Information (Addenda Type Code Record Format Specifications) (POS and SHR
17). Entries only).

2 0 1 3 O P E R AT I N G R U L E S OR71
APPENDIX TWO – Specifications for Data Acceptance by ACH Operators

• Number of Addenda Records in a Corporate Code is not a currently assigned value for
Entry Detail Record or IAT Entry Detail dishonored Returns.
Record is not numeric.
• In a contested dishonored Return with
• The Return Reason Code field for Return Contested Dishonored Return Reason Code
Entries, the Dishonored Return Reason R73 (timely original Return), the Original
Code field for dishonored Returns, or the Settlement Date is not a valid Julian date in
Contested Dishonored Return Reason Code the range 001-366, or the Date Original Entry
field for contested dishonored Returns does Returned is not a valid date.
not contain a valid code as specified in
Appendix Four (Return Entries). R27  Trace Number Error

• Dishonored Return Entries, contested • Original Entry Trace Number is not present
dishonored Return Entries, and refused COR in the Addenda Record on a Return or
Entries are not permitted for use with the IAT Notification of Change Entry.
Standard Entry Class Code.
• Trace Number of an Addenda Record is
• The Change Code field for Notification of not the same as the Trace Number of the
Change Entries or the Refused COR Code field preceding Entry Detail Record.
for refused Notification of Change Entries
does not contain a valid code as specified in R28  Routing Number Check Digit Error
Appendix Five (Notification of Change).
• The Check Digit for a routing number is not
• On a Notification of Change or Refused valid.
Notification of Change, the Corrected Data
field is blank, or on a refused Notification RDFI Not Participant in Check Truncation
R30 
of Change, the Change Code is not a Program
currently assigned value (see Appendix Five,
Notification of Change) or the COR Trace R32  RDFI Non-Settlement
Sequence Number field is not numeric. A
refused Notification of Change is denoted • The RDFI is not able to settle the Entry.
by a valid Refused COR Code in the Refused
COR Code field. See Appendix Five for a list R34  Limited Participation DFI
of valid codes.
• The RDFI’s participation has been limited by
• In a dishonored Return or contested a federal or state supervisor.
dishonored Return, the Return Trace Number
is not numeric, the Return Settlement Date is R35  Return of Improper Debit Entry
not a valid Julian Date in the range 001-366,
or the Return Reason Code is not a currently • ACH debit Entries (with the exception of
assigned value for Returns. Reversals) are not permitted for use with the
CIE Standard Entry Class Code.
• In a dishonored Return bearing Return
Reason Code R69 (Field Error), the Addenda • ACH debit Entries (with the exception of
Information Field contains all spaces or all Reversals) are not permitted to loan accounts.
zeros.
R36   Return of Improper Credit Entry
• In a contested dishonored Return, the
Dishonored Return Trace Number is not • ACH credit Entries (with the exception of
numeric, the Dishonored Return Settlement Reversals) are not permitted for use with the
Date is not a valid Julian Date in the range following Standard Entry Class Codes: ARC,
001-366, or the Dishonored Return Reason BOC, POP, RCK, TEL, WEB, and XCK.

OR72 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

The second set of Record formats (3.1.2) contains

the Company/Batch Header and Company/Batch
APPENDIX THREE Control Records. The Batch Records act as an

ACH Record Format inner envelope, combining similar Entries and

providing information about the Originator. Like
Specifications the File Records, the format of these Records
is consistent for all Entries, regardless of the
Standard Entry Class Code (with the exception of
ADV and IAT Entries). The remaining Sequence
The ACH Record format specifications are designed
of Records (3.1.3 – 3.1.24) contains the Company/
to assist ACH participants in properly formatting
Batch Header, Entry Detail Records and Addenda
and retrieving transaction information. This
Records according to Standard Entry Class Code,
appendix details the contents of the various Record
in alphabetical order.
formats and defines the code values and data
elements. The inclusion requirements, contents,
and lengths of data elements are illustrated in the
Record formats, which are arranged according to
their sequence in the File. The glossary defines
and explains the application of each field.

PART 3.1  Record Formats

The ACH Record formats appear on the following
pages. The first Record formats (3.1.1) are the
File Header and File Control Records. These two
Records act as the outermost envelope of an ACH
transaction and convey information related to the
destination and origin of the transaction, as well as
the total amount of debits and credits within the
File. The format of these Records is consistent for
all Entries, regardless of the Standard Entry Class
Code.

2 0 1 3 O P E R AT I N G R U L E S OR73
 SUBPART 3.1.1  ACH File Record Format for All Entries

OR74
ALL ENTRIES FILE HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD FILE FILE IMMEDIATE

ELEMENT TYPE PRIORITY IMMEDIATE IMMEDIATE CREATION CREATION FILE ID RECORD BLOCKING FORMAT DESTINATION IMMEDIATE REFERENCE
NAME CODE CODE DESTINATION ORIGIN DATE TIME MODIFIER SIZE FACTOR CODE NAME ORIGIN NAME CODE

Field
Inclusion
Requirement M R M M M O M M M M O O O

UPPER
CASE A-Z
Contents
NUMERIC
‘1’ Numeric bTTTTAAAAC bTTTTAAAAC YYMMDD HHMM 0-9 ‘094’ ‘10’ ‘1’ Alphameric Alphameric Alphameric

Length 1 2 10 10 6 4 1 3 2 1 23 23 8

Position 01-01 02-03 04-13 14-23 24-29 30-33 34-34 35-37 38-39 40-40 41-63 64-86 87-94

ALL ENTRIES FILE CONTROL RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5 6 7 8

DATA TOTAL DEBIT ENTRY TOTAL CREDIT ENTRY

ELEMENT RECORD TYPE ENTRY/ADDENDA DOLLAR AMOUNT DOLLAR AMOUNT
NAME CODE BATCH COUNT BLOCK COUNT COUNT ENTRY HASH IN FILE IN FILE RESERVED

Field
Inclusion
Requirement M M M M M M M N/A

Contents ‘9’ Numeric Numeric Numeric Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Blank

Length 1 6 6 8 10 12 12 39

Position 01-01 02-07 08-13 14-21 22-31 32-43 44-55 56-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.2  ACH Batch Record Format for All Entries

ALL ENTRIES COMPANY/BATCH HEADER RECORD (EXCEPT IAT)

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

STANDARD
DATA RECORD SERVICE COMPANY ENTRY COMPANY COMPANY EFFECTIVE SETTLEMENT ORIGINATOR ORIGINATING
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY CLASS ENTRY DESCRIPTIVE ENTRY DATE STATUS DFI BATCH

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) CODE IDENTIFICATION NUMBER

Field
Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric TTTTAAAA Numeric

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

ALL ENTRIES COMPANY/BATCH CONTROL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD SERVICE ENTRY/ TOTAL DEBIT TOTAL CREDIT MESSAGE

ELEMENT TYPE CLASS ADDENDA ENTRY ENTRY DOLLAR ENTRY DOLLAR COMPANY AUTHENTICATION ORIGINATING DFI BATCH
NAME CODE CODE COUNT HASH AMOUNT AMOUNT IDENTIFICATION CODE RESERVED IDENTIFICATION NUMBER

Field
Inclusion
Requirement M M M M M M R O N/A M M

Contents ‘8’ Numeric Numeric Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Alphameric Alphameric Blank TTTTAAAA Numeric

Length 1 3 6 10 12 12 10 19 6 8 7

Position 01-01 02-04 05-10 11-20 21-32 33-44 45-54 55-73 74-79 80-87 88-94

OR75
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.3  Company/Batch Header Record Format for International ACH Transaction (IAT) Entries

OR76
IAT COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
GO
FOREIGN ISO STANDARD ISO ISO IDENTIFICATION/
DATA RECORD SERVICE FOREIGN EXCHANGE FOREIGN DESTINATION ENTRY COMPANY ORIGINATING DESTINATION EFFECTIVE SETTLEMENT ORIGINATOR ORIGINATING
ELEMENT TYPE CLASS IAT EXCHANGE REFERENCE EXCHANGE COUNTRY ORIGINATOR CLASS ENTRY CURRENCY CURRENCY ENTRY DATE STATUS DFI BATCH
NAME CODE CODE INDICATOR INDICATOR INDICATOR REFERENCE CODE IDENTIFICATION CODE DESCRIPTION CODE CODE DATE (JULIAN) CODE IDENTIFICATION NUMBER
Field
Inserted by
Inclusion M M O M R R M M M M M M R M M M
ACH Operator
Requirement

Contents ‘5’ Numeric Alphameric Alphameric Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric TTTTAAAA Numeric

Length 1 3 16 2 1 15 2 10 3 10 3 3 6 3 1 8 7

Position 01-01 02-04 05-20 21-22 23-23 24-38 39-40 41-50 51-53 54-63 64-66 67-69 70-75 76-78 79-79 80-87 88-94
APPENDIX THREE – ACH Record Format Specifications

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.4  ACH File Record Format for ADV Entries

ADV FILE HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD FILE FILE IMMEDIATE IMMEDIATE

ELEMENT TYPE PRIORITY IMMEDIATE IMMEDIATE CREATION CREATION FILE ID RECORD BLOCKING FORMAT DESTINATION ORIGIN REFERENCE
NAME CODE CODE DESTINATION ORIGIN DATE TIME MODIFIER SIZE FACTOR CODE NAME NAME CODE

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M R M M M O M M M M M M O

UPPER CASE
Contents A-Z
‘1’ Numeric bTTTTAAAAC bTTTTAAAAC YYMMDD HHMM NUMERIC 0-9 ‘094’ ‘10’ ‘1’ Alphameric Alphameric Alphameric

Length 1 2 10 10 6 4 1 3 2 1 23 23 8

Position 01-01 02-03 04-13 14-23 24-29 30-33 34-34 35-37 38-39 40-40 41-63 64-86 87-94

ADV FILE CONTROL RECORD

FIELD 1 2 3 4 5 6 7 8

DATA TOTAL DEBIT ENTRY TOTAL CREDIT ENTRY

ELEMENT ENTRY/ADDENDA DOLLAR AMOUNT DOLLAR AMOUNT
NAME RECORD TYPE CODE BATCH COUNT BLOCK COUNT COUNT ENTRY HASH IN FILE IN FILE RESERVED

Field
Inclusion
Requirement M M M M M M M N/A

Contents ‘9’ Numeric Numeric Numeric Numeric $$$$$$$$$$$$$$$$$$¢¢ $$$$$$$$$$$$$$$$$$¢¢ Blank

Length 1 6 6 8 10 20 20 23

Position 01-01 02-07 08-13 14-21 22-31 32-51 52-71 72-94

OR77
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.5  Sequence of Records for ADV Entries (continued)

OR78
ADV COMPANY/BATCH CONTROL RECORD

FIELD 1 2 3 4 5 6 7 8 9

DATA
ELEMENT RECORD TYPE SERVICE CLASS ENTRY/ADDENDA TOTAL DEBIT ENTRY TOTAL CREDIT ENTRY ACH OPERATOR ORIGINATING DFI
NAME CODE CODE COUNT ENTRY HASH DOLLAR AMOUNT DOLLAR AMOUNT DATA IDENTIFICATION BATCH NUMBER

Field
Inclusion
Requirement M M M M M M O M M

Contents ‘8’ Numeric Numeric Numeric $$$$$$$$$$$$$$$$$$¢¢ $$$$$$$$$$$$$$$$$$¢¢ Alphameric TTTTAAAA Numeric

Length 1 3 6 10 20 20 19 8 7

Position 01-01 02-04 05-10 11-20 21-40 41-60 61-79 80-87 88-94

ADV ENTRY DETAIL RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ROUTING JULIAN DATE SEQUENCE
DATA RECORD DFI ADVICE ACH ADDENDA NUMBER ON WHICH NUMBER
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT ROUTING FILE OPERATOR INDIVIDUAL DISCRETIONARY RECORD OF ACH THIS ADVICE WITHIN
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER IDENTIFICATION DATA NAME DATA INDICATOR OPERATOR IS CREATED BATCH

Field
Inclusion
Requirement M M M M R M M O O R O M M M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$$$¢¢ Numeric Alphameric Alphameric Alphameric Alphameric Numeric TTTTAAAA Numeric Numeric

Length 1 2 8 1 15 12 9 5 1 22 2 1 8 3 4

Position 01-01 02-03 04-11 12-12 13-27 28-39 40-48 49-53 54-54 55-76 77-78 79-79 80-87 88-90 91-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.6  Sequence of Records for ARC Entries

ARC ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

INDIVIDUAL
NAME/
DATA RECORD RECEIVING ADDENDA

2 0 1 3 O P E R AT I N G R U L E S
ELEMENT TYPE TRANSACTION RECEIVING DFI DFI ACCOUNT CHECK SERIAL COMPANY DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION CHECK DIGIT NUMBER AMOUNT NUMBER NAME DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M M O O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

OR79
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.7  Sequence of Records for BOC Entries

OR80
BOC ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD DFI INDIVIDUAL

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT CHECK SERIAL NAME/RECEIVING DISCRETIONARY ADDENDA RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER COMPANY NAME DATA INDICATOR NUMBER

Field Inclusion
Requirement M M M M R M M O O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94
APPENDIX THREE – ACH Record Format Specifications

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.8  Sequence of Records for CCD Entries

CCD ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA ADDENDA
ELEMENT RECORD TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION RECEIVING DISCRETIONARY RECORD TRACE
NAME TYPE CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER COMPANY NAME DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

CCD ADDENDA RECORD

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

OR81
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.9  Sequence of Records for CIE Entries

OR82
CIE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD INDIVIDUAL ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT INDIVIDUAL IDENTIFICATION DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NAME NUMBER DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M R M O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

CIE ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD TYPE ADDENDA TYPE PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME CODE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.10  Sequence of Records for CTX Entries

CTX CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD DFI NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O M R N/A O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

CTX ADDENDA RECORD

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE PAYMENT RELATED INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

OR83
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.11  Sequence of Records for DNE Entries

OR84
DNE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA INDIVIDUAL ADDENDA

ELEMENT RECORD TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION INDIVIDUAL DISCRETIONARY RECORD TRACE
NAME TYPE CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

DNE ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.12  Sequence of Records for ENR Entries

ENR ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

NUMBER RECEIVING
DATA RECORD OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O M R N/A O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric 0000000000 Alphameric Numeric Alphameric Blank Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

ENR ADDENDA RECORD

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M R M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

OR85
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.13  Sequence of Records for IAT Entries

OR86
IAT ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

FOREIGN
RECEIVER’S GATEWAY
GO NUMBER ACCOUNT OPERATOR SECONDARY
DATA RECORD IDENTIFICATION/ OF NUMBER/ OFAC OFAC ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ADDENDA DFI ACCOUNT SCREENING SCREENING RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT RECORDS RESERVED AMOUNT NUMBER RESERVED INDICATOR INDICATOR INDICATOR NUMBER

Field
Inclusion M M M M M N/A M M N/A O O M M
Requirement

Contents ‘6’ Numeric TTTTAAAA Numeric Numeric Blank $$$$$$$$¢¢ Alphameric Blank Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 4 13 10 35 2 1 1 1 15

Position 01-01 02-03 04-11 12-12 13-16 17-29 30-39 40-74 75-76 77-77 78-78 79-79 80-94
APPENDIX THREE – ACH Record Format Specifications

FIRST IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

DATA RECEIVING COMPANY ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE TRANSACTION TYPE FOREIGN PAYMENT FOREIGN TRACE NAME/INDIVIDUAL SEQUENCE
NAME CODE CODE CODE AMOUNT NUMBER NAME RESERVED NUMBER

Field
Inclusion M M R R O M N/A M
Requirement

Contents ‘7’ ‘10’ Alphameric $$$$$$$$$$$$$$$$¢¢ Alphameric Alphameric Blank Numeric

Length 1 2 3 18 22 35 6 7

Position 01-01 02-03 04-06 07-24 25-46 47-81 82-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.13  Sequence of Records for IAT Entries (continued)

SECOND IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE NAME STREET ADDRESS RESERVED NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘11’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

THIRD IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE COUNTRY & POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘12’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

OR87
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.13  Sequence of Records for IAT Entries (continued)

OR88
FOURTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

ORIGINATING DFI ORIGINATING

DATA ORIGINATING IDENTIFICATION ORIGINATING DFI ENTRY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE DFI NUMBER DFI BRANCH SEQUENCE
NAME CODE CODE NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘13’ Alphameric Alphameric Alphameric Alphameric Blank Numeric

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

FIFTH IAT ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5 6 7 8

RECEIVING RECEIVING
DATA RECEIVING DFI IDENTIFICATION DFI ENTRY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE DFI NUMBER RECEIVING DFI BRANCH SEQUENCE
NAME CODE CODE NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘14’ Alphameric Alphameric Alphameric Alphameric Blank Numeric

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.13  Sequence of Records for IAT Entries (continued)

SIXTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA RECEIVER ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE IDENTIFICATION RECEIVER SEQUENCE
NAME CODE CODE NUMBER STREET ADDRESS RESERVED NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion M M O M N/A M
Requirement

Contents ‘7’ ‘15’ Alphameric Alphameric Blank Numeric

Length 1 2 15 35 34 7

Position 01-01 02-03 04-18 19-53 54-87 88-94

SEVENTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE RECEIVER RECEIVER SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE COUNTRY & POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘16’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

OR89
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.13  Sequence of Records for IAT Entries (continued)

OR90
IAT ADDENDA RECORD FOR REMITTANCE INFORMATION

FIELD 1 2 3 4 5

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE PAYMENT RELATED ADDENDA SEQUENCE
NAME CODE CODE INFORMATION SEQUENCE NUMBER NUMBER

Field
Inclusion M M O M M
Requirement

Contents ‘7’ ‘17’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

NOTE: A maximum of two optional remittance addenda records may be included with each IAT entry.

IAT ADDENDA RECORD FOR FOREIGN CORRESPONDENT BANK INFORMATION

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5 6 7 8 9

FOREIGN
CORRESPONDENT FOREIGN FOREIGN
FOREIGN BANK CORRESPONDENT CORRESPONDENT ENTRY
DATA CORRESPONDENT IDENTIFICATION BANK BANK ADDENDA DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE BANK NAME NUMBER IDENTIFICATION BRANCH SEQUENCE SEQUENCE
NAME CODE CODE QUALIFIER NUMBER COUNTRY CODE RESERVED NUMBER NUMBER

Field
Inclusion M M M M M M N/A M M
Requirement

Contents ‘7’ ‘18’ Alphameric Alphameric Alphameric Alphameric Blank Numeric Numeric

Length 1 2 35 2 34 3 6 4 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-83 84-87 88-94

NOTE: Each Foreign Correspondent Bank involved in the processing of an IAT entry must be identified within an Addenda Record for IAT Foreign Correspondent Bank Information.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.14  Sequence of Records for MTE Entries

MTE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA DFI INDIVIDUAL ADDENDA

ELEMENT RECORD TRANSACTION RECEIVING DFI CHECK ACCOUNT INDIVIDUAL IDENTIFICATION DISCRETIONARY RECORD TRACE
NAME TYPE CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NAME NUMBER DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M M M O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

MTE ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD NETWORK TERMINAL TRANSACTION

ELEMENT TYPE ADDENDA TRANSACTION IDENTIFICATION IDENTIFICATION SERIAL TRANSACTION TRANSACTION TERMINAL TERMINAL TERMINAL TRACE
NAME CODE TYPE CODE DESCRIPTION CODE CODE NUMBER DATE TIME LOCATION CITY STATE NUMBER

Field
Inclusion
Requirement M M R O R R R R R R R M

Contents ‘7’ ‘02’ Alphameric Alphameric Alphameric Alphameric MMDD HHMMSS Alphameric Alphameric Alphameric Numeric

Length 1 2 7 3 6 6 4 6 27 15 2 15

Position 01-01 02-03 04-10 11-13 14-19 20-25 26-29 30-35 36-62 63-77 78-79 80-94

OR91
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.15  Sequence of Records for POP Entries

OR92
POP ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

INDIVIDUAL
NAME/
DATA RECORD DFI CHECK RECEIVING ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT SERIAL TERMINAL TERMINAL COMPANY DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER CITY STATE NAME DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M M M M O O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 9 4 2 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-48 49-52 53-54 55-76 77-78 79-79 80-94
APPENDIX THREE – ACH Record Format Specifications

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.16  Sequence of Records for POS Entries

POS ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD INDIVIDUAL CARD ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION INDIVIDUAL TRANSACTION RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME TYPE CODE INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O R M M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

POS ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

AUTHORIZATION
DATA RECORD ADDENDA TERMINAL TRANSACTION CODE OR CARD
ELEMENT TYPE TYPE REFERENCE REFERENCE IDENTIFICATION SERIAL TRANSACTION EXPIRATION TERMINAL TERMINAL TERMINAL TRACE
NAME CODE CODE INFORMATION #1 INFORMATION #2 CODE NUMBER DATE DATE LOCATION CITY STATE NUMBER

Field
Inclusion
Requirement M M O O R R R O R R R M

Contents ‘7’ ‘02’ Alphameric Alphameric Alphameric Alphameric MMDD Alphameric Alphameric Alphameric Alphameric Numeric

Length 1 2 7 3 6 6 4 6 27 15 2 15

Position 01-01 02-03 04-10 11-13 14-19 20-25 26-29 30-35 36-62 63-77 78-79 80-94

OR93
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.17  Sequence of Records for PPD Entries

OR94
PPD ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD INDIVIDUAL ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI DFI ACCOUNT IDENTIFICATION INDIVIDUAL DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION CHECK DIGIT NUMBER AMOUNT NUMBER NAME DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

PPD ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.18  Sequence of Records for RCK Entries

RCK ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA CHECK ADDENDA

ELEMENT RECORD TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT SERIAL INDIVIDUAL DISCRETIONARY RECORD TRACE
NAME TYPE CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M M R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

OR95
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.19 Sequence of Records for SHR Entries

OR96
SHR ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD CARD DOCUMENT INDIVIDUAL CARD ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT EXPIRATION REFERENCE CARD ACCOUNT TRANSACTION RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT DATE NUMBER NUMBER TYPE CODE INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M R R R M M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ MMYY Numeric Numeric Numeric Numeric Numeric

Length 1 2 8 1 17 10 4 11 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-43 44-54 55-76 77-78 79-79 80-94

SHR ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD ADDENDA REFERENCE REFERENCE TERMINAL AUTHORIZATION

ELEMENT TYPE TYPE INFORMATION INFORMATION IDENTIFICATION TRANSACTION TRANSACTION CODE OR CARD TERMINAL TERMINAL TERMINAL TRACE
NAME CODE CODE #1 #2 CODE SERIAL NUMBER DATE EXPIRATION DATE LOCATION CITY STATE NUMBER

Field
Inclusion
Requirement M M O O R R R O R R R M

Contents ‘7’ ‘02’ Alphameric Alphameric Alphameric Alphameric MMDD Alphameric Alphameric Alphameric Alphameric Numeric

Length 1 2 7 3 6 6 4 6 27 15 2 15

Position 01-01 02-03 04-10 11-13 14-19 20-25 26-29 30-35 36-62 63-77 78-79 80-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.20  Sequence of Records for TEL Entries

TEL ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD INDIVIDUAL

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION INDIVIDUAL PAYMENT TYPE ADDENDA RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME CODE INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O M O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

OR97
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.21  Sequence of Records for TRC Entries

OR98
TRC ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD CHECK PROCESS ITEM ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT SERIAL CONTROL RESEARCH ITEM TYPE RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER FIELD NUMBER INDICATOR INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O R R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 6 16 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-60 61-76 77-78 79-79 80-94
APPENDIX THREE – ACH Record Format Specifications

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.22  Sequence of Records for TRX Entries

TRX ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD DFI NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID ITEM TYPE RECORD TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED INDICATOR INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O M R N/A O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

TRX ADDENDA RECORD

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

OR99
APPENDIX THREE – ACH Record Format Specifications
 SUBPART 3.1.23  Sequence of Records for WEB Entries

OR100
WEB ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD INDIVIDUAL PAYMENT ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT IDENTIFICATION INDIVIDUAL TYPE RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME CODE INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O M R M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

WEB ADDENDA RECORD

APPENDIX THREE – ACH Record Format Specifications

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD ADDENDA PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME TYPE CODE TYPE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 3.1.24   Sequence of Records for XCK Entries

XCK ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD CHECK PROCESS ITEM ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT SERIAL CONTROL RESEARCH DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER FIELD NUMBER DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M M R R O M M

Contents ‘6’ Numeric TTTTAAAA Numeric Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 17 10 15 6 16 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-60 61-76 77-78 79-79 80-94

OR101
APPENDIX THREE – ACH Record Format Specifications
APPENDIX THREE – ACH Record Format Specifications

PART 3.2  Glossary of ACH Record Addenda Information is associated with the
Format Data Elements immediately preceding Entry Detail Record.

SUBPART 3.2.1  Field Inclusion Requirements The Addenda Information field of a Return Entry is
The following information defines the requirements used by the RDFI to relay explanatory information
for the inclusion of certain data fields in ACH that is required with the use of Return Reason
Entries. This involves the standardization of three Codes “R11” (Check Truncation Return) and “R17”
definitions: Mandatory, Required, and Optional. (File Record Edit Criteria).

Mandatory for ACH Operator Processing. A The Addenda Information Field of a Dishonored
“Mandatory” field is necessary to ensure the Return Entry is a mandatory field when the
proper routing and/or posting of an ACH Entry. Dishonored Return bears Return Reason Code R69
Any “Mandatory” field not meeting required data (Field Errors). When using Return Reason Code
specifications will cause that Entry, batch, or File R69, the ODFI must insert the appropriate code(s)
to be Rejected by the ACH Operator. A Rejected from the list below, separated by an asterisk (*),
Entry will be returned to the ODFI by the ACH within the Addenda Information Field of the
Operator. A Rejected batch or Rejected File will Addenda Record Format for Dishonored Returns
be reported to the ODFI or Sending Point by the to indicate the field(s) in which the errors occur:
ACH Operator.
01 Return Contains Incorrect DFI Account
Required for RDFI Processing. The omission of Number
a “Required” field will not cause an Entry Reject at 02 Return Contains Incorrect Original Entry
the ACH Operator, but may cause a reject at the Trace Number
RDFI and may result in the return of the Entry.
An example is the DFI Account Number field in 03 Return Contains Incorrect Dollar Amount
the Entry Detail Record. If this field is omitted 04 Return Contains Incorrect Individual
by an ODFI, the RDFI may return the Entry as Identification Number/Identification
nonpostable. Data classified as “Required” should Number
be included by the Originator and ODFI to avoid
05 Return Contains Incorrect Transaction
processing and control problems at the RDFI.
Code
Optional. The inclusion or omission of an 06 Return Contains Incorrect Company
“Optional” data field is at the discretion of the Identification Number
Originator and ODFI. However, if a DFI does 07 Return Contains an Invalid Effective Entry
originate Files using optional data fields, the RDFI Date
must return these fields to the ODFI if the Entry
is returned. For example:  01*03*06

SUBPART 3.2.2  Glossary of Data Elements Addenda Record Indicator: 1 Position - Entry
ACH Operator Data: 19 Positions - Company/ Detail Record and Corporate Entry Detail Record
Batch Control Record – Optional (ADV); 1 Position – Mandatory (ACK, ADV, ARC, ATX, BOC, CCD,
- Entry Detail Record – Optional (ADV) CIE, CTX, DNE, ENR, IAT, MTE, POP, POS, PPD,
RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused
This field is used as specified by the ACH Operator. ACK, refused ATX, Returns, dishonored Returns,
contested dishonored Returns, COR, refused COR)
Addenda Information: 44 Positions – Addenda
Record – Optional (Returns except IAT); 34 This field indicates the existence of an Addenda
positions – Addenda Record – Optional (IAT Record.
Returns); 21 positions – Addenda Record –
Optional/​Mandatory (dishonored Returns)

OR102 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Code Values: 14 5th Addenda Record for IAT Entry

0 No Addenda Record follows the Entry 15 6th Addenda Record for IAT Entry
1 One or more Addenda Records follow the 16 7th Addenda Record for IAT Entry
Entry 17 Addenda Record for IAT Entry Remittance
Information
IAT: The value of this field for all IAT Entries,
including IAT Prenotification Entries, will always 18 
Addenda Record for IAT Entry Foreign
be “1.” Correspondent Bank Information
98 
Notification of Change (COR) Addenda
Zero dollar CCD, CTX, and IAT Entries, Notification Record and Refused Notification of Change
of Change, Refused Notification of Change, (COR) Addenda Record
Return, Dishonored Return, Contested Dishonored
Return, DNE, ENR, MTE, POS, SHR, and TRX 99 Return Entry Addenda Record, Dishonored
Entries: The value of this field will always be “1”. Return Entry Addenda Record, and
This is not applicable to MTE, POS, SHR, or TRX Contested Dishonored Return Entry
Prenotifications. Addenda Record

Addenda Sequence Number: 4 Positions – Advice Routing Number: 9 Positions – Entry

Addenda Record – Mandatory (ACK, ATX, CCD, Detail Record – Mandatory (ADV)
CIE, CTX, DNE, ENR, IAT, PPD, TRX, WEB)
This field contains the Routing number and Check
This number is consecutively assigned to each Digit of the DFI, Respondent, or Correspondent, as
Addenda Record following an Entry Detail Record. defined by the ACH Operator.
The first addenda sequence number must always
Amount: 10 Positions - Entry Detail Record –
be a “1.”
Mandatory (ACK, ARC, BOC, CCD, CIE, DNE, ENR,
Addenda Type Code: 2 Positions – Addenda IAT, MTE, POP, POS, PPD, RCK, SHR, TEL, TRC,
Record – Mandatory (ACK, ATX, CCD, CIE, CTX, WEB, XCK, refused ACK, Returns, dishonored
DNE, ENR, IAT, MTE, POS, PPD, SHR, TRX, WEB, Returns, contested dishonored Returns, COR,
Returns, dishonored Returns, contested dishonored refused COR); 12 Positions - Entry Detail Record
Returns, COR, refused COR) – Mandatory (ADV)

The Addenda Type Code defines the specific The RDFI posts the amount to the appropriate
interpretation and format for the addenda account authorized by the Receiver. A zero Amount
information contained in the Entry. is acceptable only with specific Transaction Codes.

Code Values: ADV: The Automated Accounting Advice contains

a 12 position field to record the summary debit or
02 Point of Sale Entry (POS), Shared Network credit amount.
Transaction (SHR), or Machine Transfer
Entry (MTE) ACK, ATX, COR, DNE, ENR: The value of this field is
05 
Addenda Record (Applies to ACK, ATX, always zero.
CCD, CIE, CTX, DNE, ENR, PPD, TRX, and
WEB Entries) CCD, CTX: For a zero dollar Entry, the value of this
field must be zero.
10 1st Addenda Record for IAT Entry
11 2nd Addenda Record for IAT Entry IAT: The value of this field is always reflected in
U.S. Dollars.
12 3rd Addenda Record for IAT Entry
13 4th Addenda Record for IAT Entry

2 0 1 3 O P E R AT I N G R U L E S OR103
APPENDIX THREE – ACH Record Format Specifications

Authorization Code: 6 Positions – Addenda Card Transaction Type Code: 2 Positions – Entry
Record – Optional (POS, SHR) Detail Record – Mandatory (POS, SHR, Returns,
dishonored Returns, contested dishonored
POS, SHR: This field indicates the code that a card Returns)
authorization center has furnished to the merchant.
POS, SHR: This code is used by card processors to
Batch Count: 6 Positions – File Control Record – identify the type of transaction, such as a purchase,
Mandatory (all Files) cash advance, or reversal. Values for this field are
assigned by the major card Organizations.
The value of this field must be equal to the number
of Company/Batch Header Records in the File. Code Values:
01 Purchase of goods or services
Batch Number: 7 Positions – Company/Batch
Header Record and Company/Batch Control 02 Cash
Record – Mandatory (all batches) 03 Return Reversal

The ODFI or its Sending Point assigns this number 11 Purchase Reversal
in ascending sequence to each batch in a File of 12 Cash Reversal
Entries. The batch number in the Company/Batch
13 Return
Header Record and the Company/Batch Control
Record must be the same. 21 Adjustment
99 Miscellaneous Transaction
Block Count: 6 Positions – File Control Record –
Mandatory (all Files) Change Code: 3 Positions – Addenda Record –
Mandatory (COR, refused COR)
The Block Count contains the number of blocks (a
block is 940 characters) in the File, including both A code used by the RDFI to describe the reason
the File Header and File Control Records. for Transmitting a Notification of Change. See
Appendix Five (Notification of Change) for a
Blocking Factor: 2 Positions – File Header Record complete listing of Change Codes.
– Mandatory (all Files)
Check Digit: 1 Position – Entry Detail Record,
The Blocking Factor defines the number of Records Corporate Entry Detail Record – Mandatory (all
within a block (a block is 940 characters). For all entries)
Files moving between a DFI and an ACH Operator
(either way), the value “10” must be used. If the The Check Digit is computed using Modulus 10 as
number of Records within the File is not a multiple follows:
of ten, the remainder of the block must be filled
with “9’s.” (1) Multiply each digit in the Routing number by
a weighting factor. The weighting factors for
Card Expiration Date: 4 Positions – Entry Detail each digit are:
Record – Required (SHR); 6 Positions – Addenda
Record – Optional (POS, SHR) Position: 12345678
Weights: 37137137
POS, SHR: This code is used by cardholder
processors and cardholder Financial Institutions to (2) Add the results of the eight multiplications.
verify that the card remains valid and that certain
security procedures required by various card (3) 
Subtract the sum from the next highest
authorization systems have been met. multiple of 10. The result is the Check Digit.

OR104 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Example: WEB, XCK, Returns, dishonored Returns, contested

dishonored Returns, COR, refused COR)
Routing No.: 0 7 6 4 0 1 2 5
Multiply by: 3 7 1 3 7 1 3 7 This field in the Company/Batch Header Record
Sum: 0 49  6 12  0  1  6 35 = 109 allows Originators and/or ODFIs to include codes
(one or more), of significance only to them, to
Check Digit = 1 (110 minus 109) enable specialized handling of all Entries in that
batch. There is no standardized interpretation for
Check Serial Number: 15 Positions – Entry Detail the value of the field. This field must be returned
Record – Optional (TRC, Returns, dishonored intact on any Return Entry.
Returns, contested dishonored Returns); 15
Positions – Entry Detail Record – Mandatory (ARC, CIE: This field contains the Biller’s name.
BOC, RCK, XCK); 9 Positions – Entry Detail Record
– Mandatory (POP) CTX: The Originator’s bank account number may
be placed in this field.
This field contains the Check Serial Number of a
Check. POS: The Originator (card acquirer) may place
document reference numbers or other codes
ARC, BOC, POP: This field must contain the Check significant to it.
Serial Number contained on the Eligible Source
Document used for the Entry. TRC: This field contains the city, state, and zip
code of the keeper.
Company Descriptive Date: 6 Positions –
Company/Batch Header Record – Optional (ACK, Company Entry Description: 10 Positions –
ADV, ARC, ATX, CCD, CIE, CTX, DNE, ENR, MTE, Company/Batch Header Record – Mandatory (all
POP, POS, PPD, RCK, SHR, TEL, TRC, TRX, WEB, batches)
XCK, Returns, dishonored Returns, contested
dishonored Returns, COR, refused COR) The Originator establishes the value of this field
to provide the Receiver with a description of the
Except as otherwise noted below, the Originator purpose of the Entry. For example, “Gas bill,” “Reg.
establishes this field as the date it would like Salary,” “ins. prem.,” “Soc. Sec.,” “DTC,” “Trade Pay,”
to see displayed to the Receiver for descriptive “PURCHASE,” etc.
purposes. This field is never used to control timing
of any computer or manual operation. It is solely This field must contain the word “NONSETTLED”
for descriptive purposes. The RDFI should not when the batch contains Entries that could not
assume any specific format. Examples of possible settle.
content in this field are “011311,” “01 11,” “Jan 13,”
“JAN 11,” etc. This field must contain the word “RECLAIM” when
the batch contains Reclamation Entries.
MTE, POS, and SHR: This date is the actual date
the transfer was initiated by the Receiver, and This field must contain the words “RETURN FEE”
formatted the same as the effective Entry date when the batch contains Return Fee Entries
(YYMMDD).
This field must contain the word “REVERSAL”
TRC: This field contains the date established by when the batch contains Reversing Entries.
the keeper (ODFI) for checks being truncated.
ADV: The Originator, i.e., the Originating ACH
Company Discretionary Data: 20 Positions – Operator, uses this field to describe to the institution
Company/Batch Header Record – Optional (ACK, receiving the ADV File the type of activity to which
ADV, ARC, ATX, BOC, CCD, CIE, CTX, DNE, ENR, the accounting information relates.
MTE, POP, POS, PPD, RCK, SHR, TEL, TRC, TRX,

2 0 1 3 O P E R AT I N G R U L E S OR105
APPENDIX THREE – ACH Record Format Specifications

ENR: This field must contain the word Except as otherwise noted below, this field must
“AUTOENROLL” when the batch contains contain the name by which the Originator is
Automated Enrollment Entries. known to and readily recognized by the Receiver
of the Entry.
RCK: This field must contain the word
“REDEPCHECK”. In a transaction in which the Originator of a debit
Entry is not the payee of the transaction (the party
TRX: This field contains the routing number of the to which payment is ultimately being directed),
keeper. the Company Name field of the debit Entry must
contain the name by which the payee is known
XCK: This field must contain the words “NO to and readily recognized by the Receiver of the
CHECK”. Entry. In a transaction in which the Originator of
a credit Entry is not the payor of the transaction
Company Identification: 10 Positions – Company/ (the party from which payment is ultimately being
Batch Header Record – Mandatory (all batches directed), the Company Name field of the credit
except IAT); 10 Positions – Company/Batch Control Entry must contain the name by which the payor is
Record – Required (all batches) known to and readily recognized by the Receiver
of the Entry.
The Company Identification is an alphameric code
used to identify an Originator. The Company For Return Fee Entries, this field must contain the
Identification Field must be included on all Entries. same name of the Originator as identified in the
Company Name field of the underlying Entry. For
The Company ID may begin with an ANSI one- a Return Fee Entry based on the return of a Check,
digit Identification Code Designator (ICD), the Company Name field must contain the name of
followed by the identification number. The ANSI the payee of the Check.
Identification Numbers and related Identification
Code Designators (ICD) are: ADV: The ACH Operator is both the Originator and
the ODFI. The ACH Operator originating the ADV
IRS Employer Identification Number (EIN) “1.” File identifies itself by name in this field.
Data Universal Numbering Systems (DUNS)
“3.” ARC, BOC: This field identifies the payee of the
Eligible Source Document or the payee name
User Assigned Number “9.” indicated on the bill or invoice.

CIE: This field contains the bill payment service CIE: This field contains the bill payment service
provider’s identification number. provider’s name.

IAT: For IAT Entries, the Company Identification MTE: This field identifies the owner of the terminal
Field within the Company/Batch Control Record where the transaction was initiated.
must contain the information found within
positions 41-50 (Originator Identification) of the POP, POS, SHR: This field identifies the merchant
IAT Company/Batch Header Record. with whom the Receiver initiated the transaction.

MTE (Credits): The ODFI is the company/ RCK: This field identifies the Originator of the RCK
Originator. Entry, which is the original payee on the face of
the Check.
Company Name: 16 Positions – Company/Batch
Header Record – Mandatory (all batches except TRC: This field identifies the name of the keeper.
IAT)
XCK: This field must contain the words “CHECK
This field identifies the source of the Entry and DESTROYED” (left justified).
is used for descriptive purposes for the Receiver.

OR106 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Contested Dishonored Return Reason Code: contested dishonored Returns, COR, refused COR);
3 Positions – Addenda Record – Mandatory 15 Positions – Entry Detail Record – Required
(contested dishonored Returns) (ADV)

A standard code used by the RDFI to describe the The DFI Account Number is the RDFI’s customer’s
reason for contesting a Dishonored Return. See account number. It is usually obtained from: (1)
Appendix Four (Return Entries) for a complete the “on-us” field of the MICR line of a Check; (2)
listing of Contested Dishonored Return Reason account statement; (3) passbook; or (4) other
Codes. source document provided by the RDFI that
specifically designates the account number to be
Corrected Data: 29 Positions – Addenda Record used for ACH purposes. A DFI that does not use
– Mandatory (all COR, refused COR entries except the MICR line of its Checks/share drafts for ACH
those related to IAT); 35 Positions – Addenda routing purposes (routing number and account
Record – Mandatory (COR entries related to IAT) number) is advised to print clearly the correct
routing information on the face of the Check/
The Corrected Data field is used by the RDFI to share draft.
relay corrected customer information (i.e., DFI
Account Number, Transaction Code, etc.) back to When obtaining information from the on-us
the Originator of that Entry. The Corrected Data field of the MICR line of a Check, left justify the
field in a Refused Notification of Change is copied information and enter only numbers (0 through 9)
from the Corrected Data field of the original and hyphens (-). If information is obtained from
Notification of Change. another source, alpha characters may be included.

COR Trace Sequence Number: 7 positions – If the Receiver’s account number contains
Addenda Record – Mandatory (refused COR) more than 17 valid characters, the leftmost
17 characters are inserted in the DFI Account
The last seven digits of the Trace Number contained Number field and the remaining characters
in the original Notification of Change. truncated, e.g., “012345678901234567” will appear
“01234567890123456”. If fewer than 17 characters,
Date of Death: 6 Positions – Addenda Record – left justify and leave the unused spaces blank.
Optional (Returns) Spaces within the Receiver account number must
be ignored when the Entry is formatted, e.g., “0123
The date of death is to be supplied on Entries 456789” would appear as “0123456789” and “0123-
being returned for reason of death (return reason 4 56789” would appear as “0123-456789.” Exact
codes R14 and R15). formatting of the DFI Account Number Field is
essential to ensure standard positioning of account
Date Original Entry Returned: 6 positions – number characters when Entries are received for
Addenda Record – Mandatory with R73, otherwise processing by the RDFI.
Optional (contested dishonored Returns)
ADV: Contains a 15 character DFI Account Number.
This field contains the date the RDFI initiated the
original Return. The Date Original Entry Returned ENR: Contains information provided by the
is used when a Dishonored Return Entry is Federal Government Agency participating in the
contested on the grounds that the original Return Automated Enrollment program.
was untimely (R73).
Discretionary Data: 2 Positions – Entry Detail
DFI Account Number: 17 Positions – Entry Detail Record, Corporate Entry Detail Record – Optional
Record – Required (ACK, ADV, ARC, ATX, BOC, (ACK, ADV, ARC, ATX, BOC, CCD, CIE, CTX, DNE,
CCD, CIE, CTX, DNE, ENR, MTE, POP, POS, PPD, MTE, POP, PPD, RCK, XCK, Returns, dishonored
RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused Returns, contested dishonored Returns, COR,
ACK, refused ATX, Returns, dishonored Returns, refused COR)

2 0 1 3 O P E R AT I N G R U L E S OR107
APPENDIX THREE – ACH Record Format Specifications

This field in the Entry Detail Record allows ODFIs Document Reference Number: 11 Positions –
to include codes, of significance to them, to enable Entry Detail Record – Required (SHR)
specialized handling of the Entry. There is no
standardized interpretation for the value of this This field further defines the transaction in the
field. It can either be a single two-character code, event of a Receiver’s inquiry. An example is an
or two distinct one-character codes, according to Electronic sequence number.
the needs of the ODFI and/or Originator involved.
This field must be returned intact for any returned Effective Entry Date: 6 Positions – Company/
Entry. Batch Header Record – Required (all batches)

CCD, CTX: When an Acknowledgment Entry is The Effective Entry Date is the date specified by the
requested by an Originator, this field contains Originator on which it intends a batch of Entries
“AK”. to be settled. For credit Entries, the Effective Entry
Date must be either one or two Banking Days
Dishonored Return Reason Code: Addenda following the Banking Day of processing by the
Record; 3 Positions – Addenda Record – Mandatory Originating ACH Operator (the processing date).
(dishonored Return Entry); 2 Positions – Addenda For debit Entries, the Effective Entry Date must be
Record – Mandatory (contested dishonored Return one Banking Day following the processing date.
Entry)
Batches of Entries containing an Effective Entry
A standard code used by the ODFI to describe Date beyond the designated number of days
the reason for dishonoring a Return Entry. In a allowed are Rejected by the ACH Operator and
Contested Dishonored Return Entry, this field returned to the ODFI. If this field is blank or
contains only the numeric portion of the code. zero, or partially blank or partially non-numeric,
See Appendix Four (Return Entries) for a complete or contains an incomplete date, day numbers
listing of Dishonored Return Reason Codes. higher than 31 or month numbers higher than 12,
the Originating ACH Operator inserts the Banking
Dishonored Return Settlement Date: 3 Positions Day after the processing date as the Effective Entry
– Addenda Record – Mandatory (contested Date.
dishonored Returns)
ENR: For Automated Enrollment Entries, this field
The Dishonored Return Settlement Date is used must be space filled.
in the Contested Dishonored Return format. Data
for this field is obtained from the Settlement Date Return Entries, COR, TRC, TRX: The ACH Operator
field of the Dishonored Return Company/Batch does not edit this field.
Header Record.
The scheduled Settlement Date is inserted by the
Dishonored Return Trace Number: 15 Positions Receiving ACH Operator. See the definition of
– Addenda Record – Mandatory (contested “Settlement Date” in this Appendix Three.
dishonored Returns)
Entry/Addenda Count: 6 Positions – Company/
The Dishonored Return Trace Number is used in Batch Control Record – Mandatory (all batches);
the Contested Dishonored Return format. The 8 Positions – File Control Record – Mandatory (all
data for this field is obtained from positions 80 - Files)
94 of the Addenda Record or positions 80 - 94 of
the Entry Detail Record of the Dishonored Return This count is a tally of each Entry Detail Record
Entry. and each Addenda Record processed, within either
the batch or File, as appropriate.

OR108 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Entry Detail Sequence Number: 7 Positions – File Creation Date: 6 Positions – File Header
Addenda Record – Mandatory (ACK, ATX, CCD, Record – Mandatory (all Files)
CIE, CTX, DNE, ENR, IAT, PPD, TRX, WEB, IAT
Returns) The File Creation Date is expressed in a
“YYMMDD” format. The File Creation Date is the
This field contains the ascending sequence number date on which the File is prepared by an ODFI
section of the Entry Detail or Corporate Entry (ACH input Files) or the date (exchange date) on
Detail Record’s trace number. This number is the which a File is Transmitted from ACH Operator to
same as the last seven digits of the trace number of ACH Operator, or from ACH Operator to RDFIs
the related Entry Detail Record or Corporate Entry (ACH output Files).
Detail Record.
File Creation Time: 4 Positions – File Header
Entry Hash: 10 Positions – Company/Batch Record – Optional (all Files)
Control Record and File Control Record –
Mandatory (all Files) The File Creation Time is expressed in an “HHMM”
(24 hour clock) format.
The Receiving DFI Identification in each Entry
Detail Record is hashed to provide a check File Identification: 5 Positions – Entry Detail
against inadvertent alteration of data contents due Record – Optional (ADV)
to hardware failure or program error. (NOTE:
Addenda Records are not hashed.) This field contains the File Creation Date and
File ID Modifier associated with the Automated
Company/Batch Control Record: The Entry Hash is Accounting Advice Entry.
the sum of all of the Receiving DFI Identification
fields contained within the Entry Detail Records File ID Modifier: 1 Position – File Header Record
in a batch. The Receiving DFI Identification Field – Mandatory (all Files)
contains the 8-digit routing number of the RDFI.
The hash is the sum of the 8-digit routing numbers. The File ID Modifier is provided in the File Header
Record to permit multiple Files created on the
Example #1: same date and between the same participants to be
distinguished. Only upper case A-Z and numeric
05600507 + 05140225 + 11400065 = 22140797. 0-9 are permitted.
This sum, 22140797, is placed within the Entry
Hash Field. ADV: The number in this field reflects, in
chronological order, the number of advices given
If the sum exceeds 10 characters, the Entry Hash in a particular cycle. The highest numbered advice
field must be populated with the rightmost 10 is the last advice of the cycle.
characters.
Foreign Correspondent Bank Branch Country
Example #2: Code: 3 positions – Addenda Record – Mandatory
(IAT)
If the sum of the Receiving DFI Identification
fields within a batch is 123456789012, the This field contains a 2-character code as
Entry Hash field would be populated with approved by the International Organization for
3456789012. Standardization (ISO) used to identify the country
in which the branch of the Foreign Correspondent
File Control Record: The Entry Hash is the sum Bank is located.
of the Entry Hash fields contained within the
Company/Batch Control Records of the File. If
the sum exceeds 10 characters, the field must be
populated with the rightmost 10 characters (see
example above).

2 0 1 3 O P E R AT I N G R U L E S OR109
APPENDIX THREE – ACH Record Format Specifications

Foreign Correspondent Bank Identification Fixed-to-Fixed – Entry is originated in a

“FF” 
Number: 34 Positions – Addenda Record – fixed-value amount and is to be received
Mandatory (IAT) in the same fixed-value amount in the
same currency denomination. There
This field contains the bank identification number is no foreign exchange conversion for
(i.e., the National Clearing System Number, BIC Entries Transmitted using this code.
Code, or IBAN) of the Foreign Correspondent For Entries originated in a fixed-
Bank. value amount, the Foreign Exchange
Reference Field will be space filled.
Foreign Correspondent Bank Identification
Number Qualifier: 2 Positions – Addenda Record Foreign Exchange Reference: 15 Positions –
– Mandatory (IAT) Company/Batch Header Record – Required (IAT,
Returns, COR)
This field contains a 2-digit code that identifies
the numbering scheme used in the Foreign This field contains either the foreign exchange rate
Correspondent Bank Identification Number field. used to execute the foreign exchange conversion
Code values for this field are: of an IAT Entry or another reference to the foreign
exchange transaction. Content is defined by the
01 National Clearing System Number Foreign Exchange Reference Indicator Field.
(e.g., U.S. Routing Transit Number);
02 BIC Code; or If the Foreign Exchange Indicator Field contains
“FF”, this field will always be space filled.
03 IBAN
Foreign Exchange Reference Indicator: 1
Foreign Correspondent Bank Name: 35 Positions Position – Company/Batch Header Record –
– Addenda Record – Mandatory (IAT) Required (IAT, Returns, COR)

This field identifies the name of the Foreign This field contains a code used to indicate the
Correspondent Bank. content of the Foreign Exchange Reference Field.
Code values for this field are:
Foreign Exchange Indicator: 2 Positions –
Company/Batch Header Record – Mandatory (IAT, 1 - Foreign Exchange Rate;
Returns, COR)
2 - Foreign Exchange Reference Number; or
This field contains a code used to indicate the 3 - Space Filled.
foreign exchange conversion methodology applied
to an IAT Entry. Use may be dependent on the Foreign Payment Amount: 18 Positions – Addenda
particular exchange services offered by a Gateway Record – Required (IAT, Returns)
Operator. Code values for this field are:
For Inbound IAT Entries, this field contains the
“FV” Fixed-to-Variable – Entry is originated amount for which the Entry was originated by
in a fixed-value amount and is to be the Foreign ODFI in the currency denomination
received in a variable amount resulting expressed in the Originating Currency Code
from the execution of the foreign Field of the Company/Batch Header Record. For
exchange conversion. Inbound IAT Entries returned by a U.S. RDFI,
this field is copied from the original Entry Detail
Variable-to-Fixed – Entry is originated
“VF”  Record to the Entry Detail Record for IAT Returns.
in a variable-value amount based on
a specific foreign exchange rate for For Outbound IAT Entries originated using a
conversion to a fixed-value amount in Foreign Exchange Indicator of “FV” (fixed-to-
which the Entry is to be received. variable), this field is zero-filled. For Outbound
IAT Entries using a Foreign Exchange Indicator

OR110 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

of “VF” (variable-to-fixed) or “FF” (fixed-to-fixed), For Outbound IAT Entries, this field contains the
this field contains the amount for which the Entry standard routing number, as assigned by Accuity,
is to be received by the Foreign Receiver in the that identifies the U.S. ODFI initiating the Entry.
currency denomination expressed in the ISO
Destination Currency Code Field of the Company/ GO Identification/Receiving DFI Identification:
Batch Header Record. For Outbound IAT Entries 8 Positions – Entry Detail Record – Mandatory
returned by a U.S. Gateway Operator, this field (IAT, Returns, COR)
contains the Entry amount returned to the original
ODFI. This amount will be different from the For Outbound IAT Entries, this field contains the
amount for which the original Entry was originated routing number of the U.S. Gateway Operator.
if the same rate was not used for both the forward For Inbound IAT Entries, this field contains the
and Return Entry foreign exchange conversions. standard routing number, as assigned by Accuity,
that identifies the U.S. RDFI at which the Receiver
Foreign Receiver’s Account Number/DFI maintains his account.
Account Number: 35 Positions – Entry Detail
Record – Mandatory (IAT) IAT Indicator: 16 positions – Company/Batch
Header Record – Optional (IAT, Returns); 16
For Inbound IAT Entries, this field contains the positions – Company/Batch Header Record –
U.S. Receiver’s account number. Mandatory (COR entries related to IAT)

For Outbound IAT Entries, this field contains the For forward IAT Entries, this field is left blank. For
foreign Receiver’s account number. Notifications of Change related to IAT Entries, this
field must contain the value “IATCOR.”
Foreign Trace Number: 22 Positions – Addenda
Record – Optional (IAT) Identification Number: 15 Positions – Entry Detail
Record/Corporate Entry Detail Record – Optional
For Inbound IAT Entries, this field contains (CCD, CTX, ENR, TRX, Returns, dishonored Returns,
the trace number assigned to the Entry in the contested dishonored Returns, COR, refused COR)
originating national payments system.
This field may be used by the Originator to insert
Format Code: 1 Position – File Header Record – its own number for tracing purposes.
Mandatory (all Files)
ENR: For Federal Government automated
This field must contain a value of “1.” enrollment Entries, this field is space filled.

Gateway Operator OFAC Screening Indicator: Immediate Destination: 10 Positions – File

1 Position – Entry Detail Record – Optional (IAT) Header Record – Mandatory (all Files)

This field indicates the results of a Gateway This field contains the routing number of the ACH
Operator screen for OFAC compliance. A value Operator or Receiving Point to which the File is
of “0” indicates that the Gateway Operator has not being Transmitted. The 10 character field begins
found a potential blocked party, as identified by with a blank in the first position, followed by the
OFAC on its list of Specially Designated Nationals four digit Federal Reserve Routing Symbol, the
(“SDN list”). A value of “1” indicates the potential four digit ABA Institution Identifier, and the Check
presence of a blocked party. This field must be Digit (bTTTTAAAAC).
space filled if no screening has been conducted.
Immediate Destination Name: 23 Positions – File
GO Identification/Originating DFI Header Record – Optional (all Files)
Identification: 8 positions – Company/Batch
Header Record – Mandatory (IAT, Returns, COR) This field contains the name of the ACH Operator
or Receiving Point for which that File is destined.
For Inbound IAT Entries, this field contains the
routing number of the U.S. Gateway Operator.

2 0 1 3 O P E R AT I N G R U L E S OR111
APPENDIX THREE – ACH Record Format Specifications

Immediate Origin: 10 Positions – File Header update accounts receivable Records. It should
Record – Mandatory (all Files) be the number shown on an invoice, statement,
billhead, notice or other communication as the
This field contains the routing number of the ACH reference. Numbers may be policy, customer,
Operator or Sending Point that is Transmitting the invoice, meter, sequence and/or alphanumeric
File. The 10 character field begins with a blank combinations. Field 8, rather than Field 7, of the
in the first position, followed by the four digit Entry Detail Record is used for the Individual
Federal Reserve Routing Symbol, the four digit Identification Number.
ABA Institution Identifier, and the Check Digit
(bTTTTAAAAC). MTE: Field 8, rather than Field 7, of the Entry Detail
Record is used for the Individual Identification
NOTE: This field may also be mutually defined Number.
between the ODFI and Originator. For example,
the ODFI may ask its Originator to put its tax PPD: For a Return Fee Entry related to an ARC,
identification number in this field; however, the BOC, POP, or RCK Entry or to an item that was
field must contain the routing number of the eligible to be converted to a debit Entry but was
Sending Point when the File is Transmitted to the not converted, this field must contain the check
ACH Operator. serial number contained within the ARC, BOC,
POP, or RCK Entry or item.
Immediate Origin Name: 23 Positions – File
Header Record – Optional (all Files) Individual Name: 22 positions – Entry Detail
Record – Mandatory (TEL, WEB, and Returns,
This field contains the name of the ACH Operator dishonored Returns, and contested dishonored
or Sending Point that is Transmitting the File. Returns for TEL and WEB); 22 Positions – Entry
Detail Record – Required (ADV, DNE, POS, PPD,
Individual Card Account Number: 22 Positions – RCK, Returns, dishonored Returns, contested
Entry Detail Record – Required (SHR) dishonored Returns, COR, refused COR); 22
Positions – Entry Detail Record – Optional (ARC,
The Individual Card Account Number is the number BOC, POP); 15 Positions – Entry Detail Record –
assigned by the card issuer and is obtained from Required (CIE); 15 Positions – Entry Detail Record
the card itself. – Mandatory (MTE)

Individual Identification Number: 15 Positions Except as noted below, this field is entered by the
– Entry Detail Record – Optional (DNE, POS, PPD, Originator to provide additional identification of
TEL, WEB, Returns, dishonored Returns, contested the Receiver and may be helpful in identifying
dishonored Returns, COR, refused COR); 22 returned Entries.
Positions – Entry Detail Record – Mandatory (CIE,
MTE) ADV: This field contains the name associated with
the Advice Routing Number in positions 40-48 of
Except as otherwise noted below, this field contains the Entry Detail Record.
the accounting number by which the Receiver is
known to the Originator. It is included for further ARC, BOC, POP: This field may contain the
identification and for descriptive purposes. The Receiver’s name or a reference number,
RDFI should assume no specific format to be identification number, or code that the merchant
present (e.g., presence or absence of dashes), but needs to identify the particular transaction or
can assume that the field is pre-edited so that it is customer.
suitable for description as is (including blanks in
unused positions). CIE: This field is entered by the ODFI to provide
additional identification for the Receiver and may
CIE: This field contains the accounting number be helpful in identifying returned Entries. Field 7,
by which the Originator (payor) is known to the rather than Field 8, of the Entry Detail Record is
Receiver (payee). It is used by the Receiver to used for the Individual Name.

OR112 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

MTE: Field 7, rather than Field 8, of the Entry Message Authentication Code (MAC): 19
Detail Record is used for the Individual Name. Positions – Company/Batch Control Record –
Optional (all batches)
ISO Destination Country Code: 2 Positions –
Company/Batch Header Record – Mandatory (IAT, The MAC is an eight character code derived
Returns, COR) from a special key used in conjunction with the
DES algorithm. The MAC is used to validate the
This field contains the two-character code, as authenticity of ACH Entries. The DES algorithm
approved by the International Organization for and key message standards must be in accordance
Standardization (ISO), to identify the country in with standards adopted by the American National
which the Entry is to be received. Standards Institute. The remaining eleven
characters of this field are blank.
ISO Destination Currency Code: 3 Positions –
Company/Batch Header Record – Mandatory (IAT, Network Identification Code: 3 Positions –
Returns, COR) Addenda Record – Optional (MTE)

This field contains the three-character code, as This field uniquely identifies an ATM network and
approved by the International Organization for allows for processing of MTE transactions between
Standardization (ISO), to identify the currency DFIs belonging to different networks.
denomination in which the Entry is to be received.
Number of Addenda Records: 4 Positions –
ISO Originating Currency Code: 3 Positions – Corporate Entry Detail Record/Entry Detail Record
Company/Batch Header Record – Mandatory (IAT, – Mandatory (ATX, CTX, ENR, IAT, TRX, COR (IAT
Returns, COR) entries), refused ATX); 4 Positions – Corporate
Entry Detail Record – Required (COR (except IAT),
This field contains the three-character code, as refused COR)
approved by the International Organization for
Standardization (ISO), to identify the currency CTX: This number represents the number of
denomination in which the Entry was first Addenda Records associated with the Corporate
originated. Entry Detail Record. This field will be zero filled if
Field 12 (Addenda Record Indicator Value) of the
Item Research Number: 16 Positions – Entry related Corporate Entry Detail Record contains a
Detail Record – Required (TRC, XCK) value of “0.”

This field contains the MICR locator number for ATX, ENR, IAT, TRX: This number represents the
Check item research. number of Addenda Records associated with the
Entry Detail Record.
Item Type Indicator: 2 Positions – Entry Detail
Record – Optional (TRC, TRX) Original Entry Trace Number: 15 Positions –
Addenda Record – Mandatory (Returns, dishonored
This field indicates the type of items being Returns, contested dishonored Returns, COR,
truncated. refused COR, ACK, refused ACK, ATX, refused
ATX)
Code Values:
01 NACS Truncated Items This field contains the Trace Number as originally
included on the forward Entry or Prenotification.
Julian Date on Which Advice is Created: 3 The RDFI must include the Original Entry Trace
positions – Entry Detail Record – Mandatory (ADV) Number in the Addenda Record of an Entry being
returned to an ODFI, in the Addenda Record of an
This field contains the Julian date on which an NOC, within an Acknowledgment Entry, or with an
Automated Accounting Advice is created. RDFI request for a copy of an authorization.

2 0 1 3 O P E R AT I N G R U L E S OR113
APPENDIX THREE – ACH Record Format Specifications

Original Forward Entry Payment Amount: Originating DFI Identification: 8 Positions –

10 Positions – Addenda Record – Required (IAT Company/Batch Header Record – Mandatory (all
Returns) batches except IAT); 8 Positions – Company/
Batch Control Record – Mandatory (all batches);
Outbound IAT Entries originated by a U.S. ODFI 34 Positions – Addenda Record – Mandatory (IAT)
might be returned by the Gateway Operator for
a U.S. dollar value that differs from the original This field contains the routing number of the DFI
Amount due to foreign exchange conversion. In originating the Entries within the batch.
cases when a different rate is used for the forward
and return foreign exchange conversion execution, IAT:
the value contained in this field will not equal the
value conveyed in the Amount Field of the Entry • For Inbound IAT Entries, the Originating DFI
Detail Record for Returns, which reflects the value Identification Field within the Fourth IAT
of the funds actually returned. Addenda Record must contain the National
Clearing System Number of the foreign
Original Receiving DFI Identification: 8 financial institution providing funding for the
Positions – Addenda Record – Required (Returns, payment transaction.
dishonored Returns, contested dishonored Returns,
COR, refused COR) • For Outbound IAT Entries, the Originating
DFI Identification Field within the Fourth IAT
This field contains the Receiving DFI identification Addenda Record must contain the routing
as originally included on the forward Entry or number of the U.S. ODFI.
Prenotification that the RDFI is returning or
correcting. This field must be included in the • For IAT Entries, the Originating DFI
Addenda Record for an Entry being returned to an Identification Field within the Company/
ODFI, or within the Addenda Record accompanying Batch Control Record must contain the
a Notification of Change. information found within positions 80-87
(GO/Originating DFI Identification) of the
Original Settlement Date: 3 Positions – Addenda IAT Company/Batch Header Record.
Record – Mandatory with R73, otherwise Optional
(contested dishonored Returns) Originating DFI Identification Number
Qualifier: 2 Positions – Addenda Record –
The original Settlement Date is used when a Mandatory (IAT)
Dishonored Return Entry is contested on the
grounds that the original Return was untimely This field contains a 2-digit code that identifies
(R73). It is the Settlement Date of the original the numbering scheme used in the Originating
Entry. DFI Identification Number field of the Fourth IAT
Addenda Record. Code values for this field are:
Originating DFI Branch Country Code: 3
Positions – Addenda Record – Mandatory (IAT) 01 National Clearing System Number;
02 BIC Code; or
This field contains a 2-character code, as
approved by the International Organization for 03 IBAN
Standardization (ISO), to identify the country in
which the branch of the bank that originated the Originating DFI Name: 35 Positions – Addenda
Entry is located. This code must correspond to Record – Mandatory (IAT)
the country in which the bank branch identified
within the Originating DFI Identification field of This field contains the name of the ODFI.
the Fourth IAT Addenda Record is located.
• For Inbound IAT Entries, the Originating
DFI Name Field within the Fourth IAT
Addenda Record must contain the name of

OR114 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

the foreign financial institution initiating the identification of the Originator to the ODFI. When
payment transaction, as identified within the used, this code must appear in the first position of
Originating DFI Identification field of the this field, followed by the Originator Identification,
Fourth IAT Addenda Record. as defined above.

• For Outbound IAT Entries, this field must When the ODFI has a contractual relationship with
contain the name of the U.S. ODFI. a Third-Party Sender rather than the Originator
itself, the value of this field may identify either the
Originator City and State/Province: 35 Positions Originator or the Third-Party Sender.
– Addenda Record – Mandatory (IAT)
Originator Name: 35 Positions – Addenda Record
This field contains the city and, if applicable, the – Mandatory (IAT)
state or province of the Originator. An asterisk
(“*”) must be used as the delimiter between the This field contains the name of the Originator of
data elements, and the backslash (“\”) must be the transaction.
used as the terminator following the last data
element. Originator Status Code: 1 Position – Company/
Batch Header Record – Mandatory (all batches)
Originator Country and Postal Code: 35 Positions
– Addenda Record – Mandatory (IAT) This code refers to the ODFI initiating the Entry.

This field contains the country and postal code of Code Values:
the Originator. An asterisk (“*”) must be used as 0 ADV File prepared by an ACH Operator.
the delimiter between the data elements, and the
backslash (“\”) must be used as the terminator 1 
This code identifies the Originator as a
following the last data element. depository financial institution.
2 
This code identifies the Originator as a
Originator Identification: 10 Positions – Federal Government entity or agency.
Company/Batch Header Record – Mandatory (IAT,
Returns, COR) ADV: This field must contain “0”.

The Originator Identification is an alphameric Originator Street Address: 35 Positions –

code used to uniquely identify an Originator. For Addenda Record – Mandatory (IAT)
an Originator that is not a natural Person, this
field must contain the IRS Taxpayer Identification This field contains the physical street address of
Number (TIN) of the Originator identified in the the Originator.
Originator Name Field. For an Originator that
is not a natural Person and is not established or Payment Related Information: 80 Positions –
organized under the laws of a State or the United Addenda Record – Optional (ACK, ATX, CCD, CIE,
States, this field must contain the account number CTX, DNE, ENR, IAT, PPD, TRX, WEB)
belonging to the Originator (as identified in the
Originator Name field) at the foreign financial In the Addenda Records of ACK, ATX, CCD, CIE,
institution. If this number exceeds 9 characters, ENR, IAT, PPD, and WEB Entries, an asterisk (“*”)
this field must contain the last 9 characters of the must be used as the delimiter between the data
account number belonging to the Originator at the elements, and the backslash (“\”) must be used as
foreign financial institution. If the foreign account the terminator between the data segments.
number contains 9 or fewer characters, the entire
account number must be utilized. ACK, ATX: This field contains the ANSI ASC X12
REF (Reference) data segment. This REF segment
The Originator Identification may be preceded is used to convey the Identification Number
by a one-digit alphameric code, as established
between the ODFI and the Originator, for further

2 0 1 3 O P E R AT I N G R U L E S OR115
APPENDIX THREE – ACH Record Format Specifications

contained within the original CCD or CTX Entry, DNE: Addenda Records contains the following
and/or other information of significance to the NACHA endorsed banking convention starting in
Originator. position 04:

CCD, PPD, WEB: Addenda Records contain DATE OF DEATH*MMDDYY*CUSTOMERSSN*

payment related ANSI ASC X12 data segments or #########*AMOUNT*$$$$.cc\
NACHA endorsed banking conventions (i.e., Tax
Payment, Third-Party Tax Payments, Child Support, The date of death always appears in positions
or Electronic Dealer Drafting). 18-23. If the Social Security Number (SSN) is
not available, positions 38-46 contain zeros. The
CIE: This field contains payment related ANSI ASC amount of the expected beneficiary payment
X12 data segments to further identify the payment always begins in position 55.
or Transmit additional remittance information.
ENR: This field contains the following NACHA
For Example: endorsed banking convention:
N1*BT*JohnDoe\N3*12MainStreet\N4*21070\
 ll information in this field pertains to the account
A
CTX: This field contains information formatted in holder on whose behalf the Automated Enrollment
accordance with the syntax of ANSI ASC X12.5 Entry is initiated.
and X12.6, an ASC X12 transaction set containing
a BPR or BPS data segment, or payment related Transaction Code – This field contains the
UN/EDIFACT syntax. Transaction Code of the account holder’s account.
This field contains “22” (Demand Credit), “27”
ANSI ASC X12.5 (“Interchange Control Structure”) (Demand Debit), “32” (Savings Credit), or “37”
means the standard to define the control structures (Savings Debit). (2 positions)
for the electronic interchange of business
transactions encoded in ASC X12-based syntax. Receiving DFI Identification Number -- This field
This standard provides the interchange envelope of contains the routing number used to identify the
a header and trailer for the electronic interchange DFI at which the account holder maintains its
through a data transmission, a structure to account. (8 positions)
acknowledge the receipt and processing of this
envelope, and optional, interchange-level service Check Digit – This field contains the check digit
request structures. pertaining to the routing number for the DFI at
which the account holder maintains its account.
ANSI ASC X12.6 (“Application Control Structure”) (1 position)
means the standard used to define the structure
of business transactions for computer-to-computer DFI Account Number – This field contains the
interchange. This structure is expressed using account holder’s account number. (1 - 17 positions)
a symbolic representation of X12 data in terms
of both the design and use of X12 structures, Individual Identification Number/Identification
independent of the physical representation (e.g., Number – For automated enrollments initiated
character set encoding). on behalf of consumers, this field contains the
consumer’s Social Security Number. For automated
BPR or BPS Data Segment (“Beginning Segment enrollments initiated on behalf of companies,
for Payment Order/Remittance Advice”) means this field contains the company’s Taxpayer
the beginning segment for the payment order/ Identification Number. (9 positions)
remittance advice used in ASC X12-based syntax
to indicate the beginning of a payment-related Individual Name (Surname)/Company Name –
transaction set that contains the necessary banking This field contains the consumer’s surname or the
information to process the transaction. first fifteen characters of the Company Name. (1
- 15 positions)

OR116 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Individual Name (First Name)/Company Name – For example: 123456789*PARI*FR\

This field contains the consumer’s first name or
the next seven characters of the Company Name. When the Transaction Type Code Field within the
(1 - 7 positions). First IAT Addenda Record contains MTE, POS, or
SHR, this field must contain the following NACHA-
Representative Payee Indicator/Enrollee endorsed banking convention starting in position
Classification Code – For enrollments for Federal 04:
Government benefit payments, this field contains
“0” (zero) meaning “no” or “1” (one) meaning TERMINAL IDENTIFICATION CODE(MAXIMUM
“yes” to denote whether the authorization is OF 6 CHARACTERS)*TERMINAL LOCATION
being initiated by someone other than the named (MAXIMUM OF 27 CHARACTERS)*TERMINAL
beneficiary. CITY)MAXIMUM OF 15 CHARACTERS)
*TERMINAL  STATE/FOREIGN COUNTRY
For all other enrollments, this field contains “A” (2 CHARACTERS)\
to indicate that the enrollee is a consumer, or
“B” to indicate that the enrollee is a company. For example:
(1 position)
200509*321 EAST MARKET
For Example: STREET*ANYTOWN*VA\
367802*10TH & VINE STREETS*LONDON*UK\
22*12200004*3*123987654321*777777777*DOE*JO
HN*0\ TRX: This field contains information formatted in
22*12200004*3*987654321123*876543210*ABCCO accordance with National Association for Check
MPANY**B\ Safekeeping syntax.
27*12200004*3*987654321123*876543210*ABCEL
Payment Type Code: 2 Positions – Entry Detail
ECTRONICIN*DUSTRIE*B\
Record – Required (WEB, Returns, dishonored
Returns, contested dishonored Returns); Optional
IAT: This field contains 80 characters of payment
(TEL)
related information. (Note: A maximum of two
optional Addenda Records may be used for IAT
This field is used to indicate whether an Entry is a
remittance information.)
recurring or Single-Entry payment.
When the Transaction Type Code Field within the
TEL: For a recurring TEL Entry, this field must
First IAT Addenda Record contains ARC, BOC,
contain the value “R.” For a Single-Entry TEL
or RCK, this field must contain the Check Serial
Entry, this field must either contain the value “S”
Number starting in position 04:
or be space-filled.
CHECK SERIAL NUMBER\
WEB: For a recurring WEB Entry, this field must
contain the value “R”. For a Single-Entry WEB
For example: 3349809002\
Entry, this field must contain the value “S”.
When the Transaction Type Code Field within
Priority Code: 2 Positions – File Header Record –
the First IAT Addenda Record contains POP, this
Required (all Files)
field must contain the following NACHA-endorsed
banking convention starting in position 04:
This field must contain a value of ‘01.’
CHECK SERIAL NUMBER (MAXIMUM OF 9
Process Control Field: 6 Positions – Entry Detail
CHARACTERS)*TERMINAL CITY (MAXIMUM OF
Record – Required (TRC, XCK)
4 CHARACTERS)*TERMINAL STATE/FOREIGN
COUNTRY (2 CHARACTERS)\
This field contains an optional code, as obtained
from a Check or sharedraft, which generally
identifies the document type. The field is usually

2 0 1 3 O P E R AT I N G R U L E S OR117
APPENDIX THREE – ACH Record Format Specifications

located to the right of the account number in the Receiving Company Name/ID Number: 16
on-us field of the MICR line and is sometimes Positions – Corporate Entry Detail Record –
called a transaction code. Required (ATX, CTX, ENR, TRX, refused ATX,
Returns, dishonored Returns, contested dishonored
Receiver City and State/Province: 35 Positions – Returns, COR, refused COR)
Addenda Record – Mandatory (IAT)
This field identifies the Receiver and can be used
This field contains the city and, if applicable, the for descriptive purposes. The field may contain
state or province of the Receiver. An asterisk (“*”) the Receiving Company’s name or an identifying
must be used as the delimiter between the data number for that Company.
elements, and the backslash (“\”) must be used
as the terminator following the last data element. ENR: This field contains the name of the Federal
Government agency participating in the Automated
Receiver Country and Postal Code: 35 Positions Enrollment program. (Federal Government
– Addenda Record – Mandatory (IAT) Agencies will provide this information to DFIs
initiating Automated Enrollment Entries.)
This field contains the country and postal code
of the Receiver. An asterisk (“*”) must be used Receiving Company Name/Individual Name: 35
as the delimiter between the data elements, and Positions – Addenda Record – Mandatory (IAT)
the backslash (“\”) must be used as the terminator
following the last data element. This field identifies the Receiver of the transaction.

Receiver Identification Number: 15 Positions – Receiving DFI Branch Country Code: 3 Positions
Addenda Record – Optional (IAT) – Addenda Record – Mandatory (IAT)

This field may be used by the Originator to insert This field contains a 2-character code, as
its own number for tracing purposes. approved by the International Organization for
Standardization (ISO), to identify the country in
Receiver Street Address: 35 Positions – Addenda which the branch of the bank that receives the
Record – Mandatory (IAT) Entry is located.

This field contains the physical street address of Receiving DFI Identification: 8 Positions – Entry
the Receiver. Detail Record – Mandatory (ACK, ADV, ARC, ATX,
BOC, CCD, CIE, CTX, DNE, ENR, MTE, POP, POS,
Receiving Company Name: 22 positions – Entry PPD, RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused
Detail Record – Required (ACK, CCD, refused ACK, ACK, refused ATX, Returns, dishonored Returns,
Returns, dishonored Returns, contested dishonored contested dishonored Returns, COR, refused COR);
Returns, COR, refused COR); 22 Positions – Entry 34 positions – Addenda Record – Mandatory (IAT)
Detail Record – Optional (ARC, BOC, POP)
The standard routing number as assigned by
This field is entered by the Originator to provide Accuity (with Check Digit) is used to identify the
additional identification of the Receiver and may DFI in which the Receiver maintains his account or
be helpful in identifying Return Entries. a routing number assigned to a Federal Government
agency by the Federal Reserve. For IAT Entries,
ARC, BOC, POP: This field may contain the this field contains the bank identification number
Receiver’s name or a reference number, of the DFI at which the Receiver maintains his
identification number, or code that the merchant account.
needs to identify the particular transaction or
customer. ENR: This field contains the routing number
assigned to a Federal Government agency for the
purpose of the automated enrollment process. Any
Entry with a dollar value directed to that routing

OR118 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

number in error is not subject to compensation Reference Information #1: 7 Positions – Addenda
rights as provided in these Rules. Record – Optional (POS, SHR)

Receiving DFI Identification Number Qualifier: This field may be used for additional reference
2 Positions – Addenda Record – Mandatory (IAT) numbers, identification numbers, or codes that
the merchant needs to identify the particular
This field contains a 2-digit code that identifies transaction or customer.
the numbering scheme used in the Receiving DFI
Identification Number field. Code values for this Reference Information #2: 3 Positions – Addenda
field are: Record – Optional (POS, SHR)

01 National Clearing System Number; This field may be used for additional reference
numbers, identification numbers, or codes that
02 BIC Code; or
the merchant needs to identify the particular
03 IBAN. transaction or customer.

Receiving DFI Name: 35 Positions – Addenda Refused Acknowledgment Code: 2 positions –

Record – Mandatory (IAT) Corporate Entry Detail Record, Entry Detail Record
– Mandatory (Refused ACK, Refused ATX)
This field contains the name of the Receiving
Depository Financial Institution. This field contains a standard code used by
an ODFI to describe the reason for refusing an
Record Size: 3 Positions – File Header Record – acknowledgment Entry.
Mandatory (all Files)
Refused COR Code: 3 Positions – Addenda Record
The Record Size Field indicates the number of – Mandatory (Refused COR)
characters contained in each Record. The value
“094” must be used. This field contains a standard code used by
the RDFI to designate the reason for refusing a
Record Type Code: 1 Position – All Record Notification of Change Entry. See Appendix Five
Formats – Mandatory (all Records) (Notification of Change) for a complete listing of
Change Codes.
Code Values:
1 File Header Record Format Return Reason Code: 3 Positions – Addenda
Record – Mandatory (Returns); 2 Positions –
5 Company/Batch Header Record Format
Addenda Record – Mandatory (dishonored Returns,
6 Entry Detail Record Format (Consumer contested dishonored Returns)
and Corporate)
This field contains a standard code used by an
7 Addenda Record Formats
ACH Operator or RDFI to describe the reason for
8 Company/Batch Control Record Format returning an Entry. In a Dishonored Return Entry
9 File Control Record Format and Contested Dishonored Return Entry, only the
numeric portion of the code is used. See Appendix
Reference Code: 8 Positions – File Header Record Four (Return Entries) for a complete listing of
– Optional (all Files) Return Reason Codes.

This field is reserved for information pertinent to Return Settlement Date: 3 Positions – Addenda
the Originator. Record – Mandatory (dishonored Returns,
contested dishonored Returns)
ADV: This field must contain “ADV FILE”.
The Return Settlement Date is used in the
Dishonored Return format. The data for this field

2 0 1 3 O P E R AT I N G R U L E S OR119
APPENDIX THREE – ACH Record Format Specifications

is obtained from the Settlement Date field in the Settlement Date: 3 Positions – Company/Batch
Company/Batch Header of the Return Entry. Header Record – Inserted by Receiving ACH
Operator (all batches)
Return Trace Number: 15 Positions – Addenda
Record – Mandatory (dishonored Returns, The Settlement Date (a 3-digit Julian date) for
contested dishonored Returns) a batch of Entries is inserted by the Receiving
ACH Operator. This is the date on which the
The Return Trace Number is used in the Dishonored Participating DFI or its correspondent is scheduled
Return format. The data for this field is obtained to be debited or credited by the Federal Reserve.
from positions 80 - 94 of the Addenda Record or
positions 80 -94 of the Entry Detail Record of the The Settlement Date inserted by the Receiving
Return Entry. ACH Operator is the same as the Effective Entry
Date designated by the Originator unless the
Routing Number of ACH Operator: 8 positions – Effective Entry Date is the same as or earlier than
Entry Detail Record – Mandatory (ADV) the Originating ACH Operator’s processing date
(the Banking Day of processing). In these cases,
This field contains the routing number of the ACH the scheduled Settlement Date will be the Banking
Operator that is Transmitting the File. Day following the Banking Day of processing.

Secondary OFAC Screening Indicator: 1 Position Returns, dishonored Returns, and contested
– Entry Detail Record – Optional (IAT) dishonored Returns are settled by the ACH
Operator no earlier than the Effective Entry Date
This field indicates the results of a Third-Party contained within the original Entry, as it appears in
Service Provider screen for OFAC compliance. A the Return Entry Company/Batch Header Record.
value of “0” indicates that the Third-Party Service The return of an Entry that contains an invalid or
Provider has not found a potential blocked party, stale Effective Entry Date will be settled by the
as identified by OFAC on its list of Specially ACH Operator at the earliest opportunity (i.e., the
Designated Nationals (“SDN list”). A value of “1” Banking Day of processing or the next Banking
indicates the potential presence of a blocked party. Day).
This field must be space filled if no screening has
been conducted. Notifications of Change and TRC/TRX Entries
will be settled at the earliest opportunity, i.e., the
Sequence Number Within Batch: 4 positions – Banking Day of processing or the next Banking
Entry Detail Record – Mandatory (ADV) Day.

This field contains the sequence number of an Standard Entry Class Code: 3 Positions –
Entry Detail Record within a batch of Entries. Company/Batch Header – Mandatory (all batches)

Service Class Code: 3 Positions – Company/ This field contains a three-character code used to
Batch Header Record and Company/Batch Control identify various types of Entries.
Record – Mandatory (all batches)
CK: ACH Payment Acknowledgment –
A
The Service Class Code (BAI Specifications) The code that identifies a Non-Monetary
identifies the general classification of dollar Entry initiated by an RDFI to provide an
Entries to be exchanged. ACH Entries are assigned acknowledgment of receipt by the RDFI of a
Service Class Code series 200-299. corporate credit payment originated using the
CCD format.
Code Values:
200 ACH Entries Mixed Debits and Credits ADV: Automated Accounting Advice – The
code that identifies a Non-Monetary Entry
220 ACH Credits Only that is used by an ACH Operator to provide
225 ACH Debits Only
280 ACH Automated Accounting Advices

OR120 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

accounting information regarding an Entry ODFI to refuse a misrouted NOC or an NOC

to Participating DFIs in machine readable that contains incorrect information.
format. An Automated Accounting Advice is an
optional service provided by ACH Operators TX: Corporate Trade Exchange – The
C
and must be requested by a DFI desiring this code that identifies an Entry initiated by an
service. Organization to transfer funds to or from
the account of that Organization or another
ARC: Accounts Receivable Entry – The code Organization that permits the inclusion of
that identifies a Single Entry debit initiated by payment related remittance information in
an Originator to the Receiver’s account based ANSI or UN/EDIFACT syntax.
on an Eligible Source Document provided
to the Originator by the Receiver (1) via the  NE: Death Notification Entry – The code that
D
U.S. mail or delivery service, (2) at a dropbox identifies a Non-Monetary Entry initiated by
location, or (3) in person for payment of a bill an agency of the Federal Government of the
at a manned location. United States to notify an RDFI of the death of
a Receiver.
TX: Financial EDI Acknowledgment –
A
The code that identifies a Non-Monetary ENR: Automated Enrollment Entry – The code
Entry initiated by an RDFI to provide an that identifies a Non-Monetary Entry initiated
acknowledgment of receipt by the RDFI of a by a Participating DFI to an agency of the
corporate credit payment originated using the Federal Government of the United States
CTX format. on behalf, and at the request, of an account
holder at the Participating DFI to enroll in a
 OC: Back Office Conversion Entry – The code
B service that will enable Entries to such Person’s
that identifies a Single Entry debit initiated by account at the Participating DFI.
an Originator to the Receiver’s account based
on an Eligible Source Document provided to IAT: International ACH Transaction – The
the Originator by the Receiver at the point of code that identifies an Entry that is part of
purchase or at a manned bill payment location a payment transaction1 involving a Financial
for subsequent conversion during back office Agency’s office that is not located in the
processing. territorial jurisdiction of the United States.
An office of a Financial Agency is involved
 CD: Corporate Credit or Debit Entry – The
C in the payment transaction if it (1) holds an
code that identifies an Entry initiated by an account that is credited or debited as part of
Organization to transfer funds to or from the payment transaction, (2) receives payment
an account of that Organization or another directly from a Person or makes payment
Organization. directly to a Person as part of the payment
transaction, or (3) serves as an intermediary
 IE: Customer Initiated Entry – The code that
C in the settlement of any part of the payment
identifies a credit Entry initiated by or on transaction.
behalf of the holder of a Consumer Account to
transfer funds to the account of the Receiver.  TE: Machine Transfer Entry – The code that
M
identifies Entries initiated at an “Electronic
OR: Notification of Change or Refused
C terminal,” as defined in Regulation E, to
Notification of Change – The code that transfer funds to or from a Consumer Account
identifies a Non-Monetary Entry Transmitted maintained with an RDFI, i.e., an ATM cash
by (1) an RDFI for the purpose of identifying deposit or withdrawal.
incorrect information contained within an
Entry and providing correct data in the precise  OP: Point-of-Purchase Entry – The code that
P
format to be used on future Entries, or (2) an identifies a Single Entry debit initiated by an
1
See the NACHA Operating Guidelines chapter on International ACH
Transactions for further guidance on payment transactions.

2 0 1 3 O P E R AT I N G R U L E S OR121
APPENDIX THREE – ACH Record Format Specifications

Originator to the Receiver’s account based on  RC: Check Truncation Entry – The code that
T
an Eligible Source Document provided to the identifies a debit Entry initiated pursuant to
Originator by the Receiver at the point-of- a Check Truncation Program that permits the
purchase or manned bill payment location to Truncation of a single Check drawn on the
transfer funds from the Receiver’s account. paying bank.

OS: Point of Sale Entry – The code that

P  RX: Check Truncation Entries Exchange –
T
identifies a debit Entry initiated at an The code that identifies a debit Entry initiated
“Electronic terminal,” as defined in Regulation based on a Check Truncation Program that
E, to transfer funds from a Consumer Account permits the Truncation of multiple Checks
of the Receiver to pay an obligation incurred in drawn on the same paying bank.
a point-of-sale transaction, or to effect a point-
of-sale terminal cash withdrawal. Also an  EB: Internet-Initiated/Mobile Entry – The
W
adjusting or other credit Entry related to such code that identifies a debit Entry initiated
debit Entry, transfer of funds, or obligation. by an Originator to a Consumer Account of
the Receiver based on (1) an authorization
 PD: Prearranged Payment and Deposit Entry
P that is communicated, other than by an oral
– The code that identifies an Entry initiated communication, from the Receiver to the
by an Organization based on a standing or a Originator via the Internet or a Wireless
Single Entry authorization from a Receiver to Network, or (2) any form of authorization if
transfer funds to or from a Consumer Account the Receiver’s instruction for the initiation of
of the Receiver. the individual debit Entry is designed by the
Originator to be communicated, other than by
 CK: Re-presented Check Entry – The code
R an oral communication, to the Originator via a
that identifies a Single Entry debit constituting Wireless Network.
a presentment notice of an item eligible under
Article Two, Subsection 2.5.13.3 (RCK Eligible XCK: Destroyed Check Entry – The code that
Items). An RCK Entry is an item as defined by identifies a debit Entry initiated with respect to
Revised Article 4 of the Uniform Commercial an item eligible under Article Two, subsection
Code (1990 Official Text) only for the limited 2.5.18.2 (XCK Eligible Items).
purposes of presentment as set forth in Article
4-110(c) and notice of dishonor as set forth in Terminal City: 15 Positions – Addenda Record
Article 4-301(a)(2). – Required (MTE, POS, SHR); 4 Positions – Entry
Detail Record – Mandatory (POP)
S HR: Shared Network Transaction – The code
This field identifies the city, town, village or
that identifies a debit Entry initiated at an
township in which an Electronic terminal is
“Electronic terminal,” as defined in Regulation
located.
E, to transfer funds from a Consumer Account
of the Receiver to pay an obligation incurred
POP: This field contains a truncated name or
in a point-of-sale transaction, or to effect a
abbreviation to identify the city, town, village,
point-of-sale terminal cash withdrawal. Also an
or township in which the Electronic terminal is
adjusting or other credit Entry related to such
located.
debit Entry, transfer of funds, or obligation.
SHR Entries are initiated in a shared network Terminal Identification Code: 6 Positions –
where the ODFI and RDFI have an agreement Addenda Record – Required (MTE, POS, SHR)
in addition to these Rules to process such
Entries. This field identifies an Electronic terminal with a
unique code that allows a terminal owner and/
 EL: Telephone-Initiated Entry – The code that
T or switching network to identify the terminal at
identifies a debit initiated by an Originator which an Entry originated.
pursuant to an oral authorization obtained
over the telephone to transfer funds from a
Consumer Account of the Receiver.

OR122 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

Terminal Location: 27 Positions – Addenda Transmission (File Creation) Date, and File ID
Record – Required (MTE, POS, SHR) Modifier, the Trace Number uniquely identifies an
Entry within a specific File. For Addenda Records,
This field identifies the specific location of a the Trace Number is identical to the Trace Number
terminal (i.e., street names of an intersection, in the associated Entry Detail Record.
address, etc.) in accordance with the requirements
of Regulation E. Throughout the entire processing cycle (from
ODFI to RDFI) the Trace Number is retained with
Terminal State: 2 Positions – Addenda Record – the Entry. The Trace Number is critical in routing
Required (MTE, POS, SHR); 2 Positions – Entry returned Entries from the RDFI back to the ODFI
Detail Record – Mandatory (POP) through the ACH.

This field identifies the state of the United States in Since it is possible, although undesirable, for an
which an Electronic terminal is located. ODFI to duplicate Trace Numbers on separate
Files or within different batches submitted during
Total Amount: 10 Positions – Corporate Entry the same processing date, the File ID Modifier
Detail Record – Mandatory (ATX, CTX, TRX, contained in the ODFI’s File Header Record should
refused ATX, Returns, dishonored Returns, also be referenced when the ODFI is tracing
contested dishonored Returns, COR, refused COR) returned Entries.
The net dollar value of all items paid to the same
The Trace Number is constructed as follows:
business is the total amount. The RDFI posts this
total amount to the appropriate account.
Positions
ATX: The value of this field must always be zero. 01 - 08 
Routing number of ODFI (the
Originating DFI Identification).
Total Debit or Credit Entry Dollar Amount (all
Files): 12 positions – Company/Batch Control and 09 - 15 E
 ntry Detail Sequence Number –
File Control Records – Mandatory (all Standard The number assigned in ascending
Entry Class Codes except ADV); 20 positions – order to each Entry within each
Company/Batch Control and File Control Records batch. Provisions should be made
– Mandatory (ADV) by the ODFI to avoid duplication of
Trace Numbers if multiple data Files
These fields contain accumulated Entry Detail debit are prepared on the same day. Trace
and credit totals within a specific batch (Company/ Numbers are not required to be
Batch Control Record) and accumulated Company/ contiguous.
Batch Control Record debit and credit totals within
a specific File (File Control Record). Transaction Code: 2 Positions – Entry Detail
Record – Mandatory (ACK, ADV, ARC, ATX, BOC,
Trace Number: 15 Positions – Entry Detail Record, CCD, CIE, CTX, DNE, ENR, IAT, MTE,POP, POS,
Corporate Entry Detail Record, and Addenda PPD, RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused
Records – Mandatory (ACK, ARC, ATX, BOC, CCD, ACK, refused ATX, Returns, dishonored Returns,
CIE, CTX, DNE, ENR, IAT, MTE, POP, POS, PPD, contested dishonored Returns, COR, refused COR)
RCK, SHR, TEL, TRC, TRX, WEB, XCK, refused
ACK, refused ATX, Returns, dishonored Returns, Transaction Codes identify various types of debit
contested dishonored Returns, COR, refused COR) and credit Entries.

A Trace Number, assigned by the ODFI in ascending Code Values:

sequence, is included in each Entry Detail Record,
Corporate Entry Detail Record, and Addenda Demand Credit Records (for checking, NOW,
Record. A Trace Number uniquely identifies each and share draft accounts)
Entry Detail Record within a batch in an ACH 20 Reserved
input File. In association with the Batch Number, 21 
Return or Notification of Change for
original transaction code 22, 23, or 24

2 0 1 3 O P E R AT I N G R U L E S OR123
APPENDIX THREE – ACH Record Format Specifications

22 Demand Credit 
Financial Institution General Ledger Debit
23 Prenotification of Demand Credit; Death Records
Notification (non-dollar); Automated 46 Return or Notification of Change for
Enrollment Entry (non-dollar) original transaction code 47, 48, or 49
24  Zero dollar with remittance data (for 47 General Ledger Debit
CCD, CTX, and IAT Entries only); 48 Prenotification of General Ledger Debit
Acknowledgment Entries (ACK and ATX (non-dollar)
Entries only) 49 Zero dollar with remittance data (for CCD
and CTX only)
Demand Debit Records (for checking, NOW,
and share draft accounts) Loan Account Credit Records
25 Reserved 51 Return or Notification of Change for
26 Return or Notification of Change for original transaction code 52, 53, or 54
original transaction code 27, 28, or 29 52 Loan Account Credit
27 Demand Debit 53 Prenotification of Loan Account Credit
28 Prenotification of Demand Debit (non- (non-dollar)
dollar) 54 Zero dollar with remittance data (for CCD
29 Zero dollar with remittance data (for CCD, and CTX Entries only)
CTX, and IAT Entries only)
Loan Account Debit Records (for Reversals
Savings Account Credit Records
Only)
30 Reserved
31 Return or Notification of Change for 55 Loan Account Debit (Reversals Only)
original transaction code 32, 33, or 34 56 Return or Notification of Change for
32 Savings Credit original transaction code 55
33 Prenotification of Savings Credit; Death
Accounting Records (for use in ADV Files only)
Notification (non-dollar); Automated
Enrollment Entry (non-dollar) These transaction codes represent accounting
34 Zero dollar with remittance data (for Entries.
CCD, CTX, and IAT Entries only);
Acknowledgment Entries (ACK and ATX 81 Credit for ACH debits originated
Entries only) 82 Debit for ACH credits originated
83 Credit for ACH credits received
Savings Account Debit Records 84 Debit for ACH debits received
35 Reserved 85 Credit for ACH credits in Rejected batches
36 Return or Notification of Change for 86 Debit for ACH debits in Rejected batches
original transaction code 37, 38, or 39 87 Summary credit for respondent ACH
37 Savings Debit activity
38 Prenotification of Savings Debit (non- 88 Summary debit for respondent ACH
dollar) activity
39 Zero dollar with remittance data (for CCD,
CTX, and IAT Entries only) Transaction Date: 4 Positions – Addenda Record
– Required (MTE, POS, SHR)
Financial Institution General Ledger Credit
Records This date, expressed MMDD, identifies the date on
41 Return or Notification of Change for which the transaction occurred.
original transaction code 42, 43, or 44
42 General Ledger Credit Transaction Description: 7 Positions – Addenda
43 Prenotification of General Ledger Credit Record – Required (MTE)
(non-dollar)
44 Zero dollar with remittance data (for CCD This field describes the transaction in accordance
and CTX Entries only) with Regulation E. Possible descriptions include:

OR124 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX THREE – ACH Record Format Specifications

CHK–DEP (Checking Deposit) to which the Entry relates, as well as terminal

SAV–DEP (Savings Deposit) information (city and state or foreign country)
PAYMENT for the POP Entry. When this field contains MTE,
CHK–SAV (Transfer: checking to savings) POS, or SHR, the Payment Related Information
SAV–CHK (Transfer: savings to checking) field of the IAT Addenda Record for Remittance
CHK–WDL (Checking Withdrawal) Information must contain the terminal information
SAV–WDL (Savings Withdrawal) (terminal identification code, terminal location,
ADVANCE (Credit Card Cash Advance) terminal city, and terminal state or foreign country)
for the MTE, POS, or SHR Entry.
Transaction Serial Number: 6 Positions –
Addenda Record – Required (MTE, POS, SHR)

This number is assigned by the terminal at the

time the transaction is originated. The number,
with the Terminal Identification Code, serves as
an audit trail for the transaction and is usually
assigned in ascending sequence.

Transaction Time: 6 Positions – Addenda Record

– Required (MTE)

This field identifies the time of day a transaction

is originated at a terminal. It is expressed in
HHMMSS format.

Transaction Type Code: 3 Positions – Addenda

Record – Required (IAT)

Code values are “ANN” (Annuity), “BUS” (Business/

Commercial), “DEP” (Deposit), “LOA” (Loan),
“MIS” (Miscellaneous), “MOR” (Mortgage), “PEN”
(Pension), “REM” (Remittance), “RLS” (Rent/
Lease), “SAL” (Salary/Payroll), “TAX” (Tax), “ARC”
(Accounts Receivable Entry), “BOC” (Back Office
Conversion Entry), “MTE” (Machine Transfer
Entry), “POP” (Point of Purchase Entry), “POS”
(Point of Sale Entry), “RCK” (Re-presented Check
Entry), “SHR” (Shared Network Transaction), “TEL”
(Telephone-Initiated Entry), and “WEB” (Internet-
Initiated Entry).

When this field contains ARC, BOC, or RCK, the

Payment Related Information field of the IAT
Addenda Record for Remittance Information must
contain the Check Serial Number of the Eligible
Source Document/item to which the Entry relates.
When this field contains POP, the Payment Related
Information field of the IAT Addenda Record for
Remittance Information must contain the Check
Serial Number of the Eligible Source Document

2 0 1 3 O P E R AT I N G R U L E S OR125
APPENDIX FOUR – Return Entries

(NOTE: This includes the original SEC code

found in Field 51-53 of the Company/Batch
APPENDIX FOUR Header Record.) In general, Addenda Records
Return Entries transmitted with the original Entry are not copied
for return to the Originator. However, IAT Return
Entries must include all mandatory Addenda
Records Transmitted with the forward IAT Entry.
An RDFI may return Entries for any reason, except
(Note: IAT Addenda Records related to Foreign
as otherwise provided in Article Three, Subsection
Correspondent Banks and those that contain
3.8.1 (Restrictions on RDFI’s Right to Transmit
remittance information are not Transmitted with
Return Entries) of these Rules. The RDFI must use
IAT Return Entries.)
an appropriate Return Reason Code as specified
in this Appendix Four. If it uses Return Reason
The Return Entry is a new Entry. These Entries
Code R11 or R17, it must specify the reason for the
must be assigned new batch and trace numbers,
Return. If no appropriate Return Reason Code is
new identification numbers for the returning
defined within this Appendix Four, the RDFI must
institution, appropriate transaction codes, etc., as
use the code that most closely approximates the
required per format specifications.
reason for Return.

PART 4.1  Return Entries

NOTE: Throughout this section, DFIs are
designated by their original names. For example,
the ODFI is the DFI that initially prepared the
original Entry, and that will eventually have the
Return Entry delivered to it. The RDFI is the
DFI that received the original Entry and usually
prepares the Return Entry. In some cases, a Return
Entry may be prepared by an ACH Operator if
the Entry cannot be delivered or if it contains an
erroneous condition.

When a Return Entry is prepared, the original

Company/Batch Header Record, the original Entry
Detail Record, and the Company/Batch Control
Record are copied for return to the Originator.

OR126 2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R01 Insufficient The available and/or cash RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8
Funds reserve balance is not Non-Consumer - RDFI’s Right to Transmit
sufficient to cover the dollar Return Entries.
value of the debit Entry.
R02 Account Closed A previously active account RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8
has been closed by action of Non-Consumer - RDFI’s Right to Transmit

2 0 1 3 O P E R AT I N G R U L E S
the customer or the RDFI. Return Entries.
R03 No Account/ The account number RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 This Return Reason Code may
Unable to structure is valid and it Non-Consumer - RDFI’s Right to Transmit not be used to return ARC,
Locate Account passes the Check digit Return Entries. BOC, or POP Entries solely
validation, but the account because they do not contain the
number does not correspond Receiver’s name in the Individual
to the individual identified Name/Receiving Company
in the Entry, or the account Name Field.
number designated is not an
existing account.

R04 Invalid Account The account number RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 The Entry may fail the Check
Number structure is not valid. Non-Consumer - RDFI’s Right to Transmit digit validation or may contain an
Structure Return Entries. incorrect number of digits.
R05 Unauthorized CCD or CTX debit Entry was RDFI Extended Consumer ** 60 Calendar Days Yes Article Three, Section 3.13
Debit to transmitted to a Consumer Return - RDFI Right to Transmit
Consumer Account of the Receiver and Extended Return Entries.
Account Using was not authorized by the Article Three, Subsection
Corporate SEC Receiver. 3.12.1 - Unauthorized Debit
Code Entry.
Article Three, Subsection
3.4.1.2 -Rule Exception for
CCD and CTX Entries to
Consumer Accounts.
R06 Returned per The ODFI has requested that RDFI Return Consumer or Not defined, No Article Two, Subsection 2.12.2 If the RDFI agrees to return the
ODFI’s Request the RDFI return an Erroneous Non-Consumer determined by ODFI - ODFI Request for Return. Entry, the ODFI must indemnify
Entry. and RDFI. the RDFI according to Article
Two, Subsection 2.12.3.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR127
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR128
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R07 Authorization The RDFI’s customer (the RDFI Extended Consumer ** 60 Calendar Days Yes Article Three, Section 3.13 This Return Reason Code may
Revoked by Receiver) revoked the Return - RDFI Right to Transmit not be used for ARC, BOC, POP,
Customer authorization previously Extended Return Entries. or RCK Entries..
provided to the Originator for Article Three, Subsection
this debit Entry. 3.12.1 - Unauthorized Debit
Entry
R08 Payment The Receiver has placed a RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.7 A stop payment order may be
Stopped stop payment order on this Non-Consumer - RDFI Obligation to Stop placed on one or more debit
debit Entry. Payment. Entries.
APPENDIX FOUR – Return Entries

R09 Uncollected A sufficient ledger balance RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8
Funds exists to satisfy the dollar Non-Consumer - RDFI’s Right to Transmit
value of the transaction, Return Entries.
but the available balance is
below the dollar value of the
debit Entry.
R10 Customer The RDFI has been notified RDFI Extended Consumer; for ** 60 Calendar Days Yes Article Three, Subsection May be used for any Entry
Advises Not by the Receiver that the Entry Return ARC, BOC, IAT, 3.12.1 - Unauthorized Debit except CCD or CTX Entries
Authorized, is unauthorized, improper, or or POP, Entries Entry. For CCD or CTX Entries to
Improper, or ineligible. may also be a Article Three, Subsection Consumer Accounts, see R05.
u Ineligible The RDFI has been notified Non-Consumer. 3.12.2 - Improper ARC, BOC, For CCD or CTX to Non-
Customer by the Receiver that the Entry See note for POP, and RCK Debit Entries. Consumer Accounts, see R29.
Advises Not is unauthorized, improper, additional Article Three, Subsection May also be used to return an
Authorized, ineligible, or part of an exceptions. 3.12.3- Incomplete unauthorized debit Entry to a
Improper, Incomplete Transaction. Transaction. non-consumer account if the
Ineligible, or
part of an Article Three, Subsection 3.1.3 debit Entry contains a consumer
Incomplete - RDFI May Rely on Standard SEC Code.
Transaction Entry Class Codes.
Article Three, Subsection
3.4.1.2 Rule Exception for
CCD and CTX Entries to
Consumer Accounts.
Article Three, Section 3.13
- RDFI Right to Transmit
Extended Return Entries.
Article Eight, Section 8.46 -
Incomplete Transaction.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
uApproved April 2, 2012, Effective March 15, 2013
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R11 Check Used when returning a Check RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 This Return Reason Code
Truncation truncation Entry. Non-Consumer - RDFI’s Right to Transmit should be used only if no
Entry Return Return Entries. other code is applicable. The
RDFI must use the Addenda
Information field in the Return
addenda record to specify the

2 0 1 3 O P E R AT I N G R U L E S
reason for return (i.e. “exceeds
dollar amount,” “stale date,”
etc.).
R12 Account Sold to A financial institution received RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8
Another DFI an Entry to an account that Non-Consumer - RDFI’s Right to Transmit
was sold to another financial Return Entries.
institution.
R13 Invalid ACH Entry contains a Receiving ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Routing DFI Identification or Gateway Return Non-Consumer following processing (Automatic Entry Detail
Number Identification that is not a Rejection Criteria).
valid ACH routing number.
R14 Representative The representative payee is RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 The representative payee is a
Payee either deceased or unable to Non-Consumer - RDFI’s Right to Transmit person or institution authorized
Deceased continue in that capacity. The Return Entries. to accept Entries on behalf of
or Unable to beneficiary is not deceased. one or more other persons, such
Continue in as legally incapacitated adults or
That Capacity minor children.
R15 Beneficiary or (1)  The beneficiary is RDFI Return Consumer * 2 Banking Days No Article Three, Section 3.8 (1) The beneficiary is the person
Account Holder deceased, or - RDFI’s Right to Transmit entitled to the benefits and
(Other Than a (2)  The account holder is Return Entries. may or may not be the account
Representative deceased. holder; or
Payee) (2) The account holder is the
Deceased owner of the account and is not
a representative payee.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR129
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR130
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R16 Account Frozen Access to the account is RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8
restricted due to specific Non-Consumer - RDFI’s Right to Transmit
action taken by the RDFI or Return Entries.
by legal action.

n 1) Access to the account is RDFI or Return Consumer or * 2 Banking Days No Article Three, Section 3.8
Account
restricted due to specific Gateway Non-Consumer - RDFI’s Right to Transmit
Frozen/Entry
action taken by the RDFI Return Entries.
Returned
Per OFAC or by legal action; or (2)
APPENDIX FOUR – Return Entries

Instruction OFAC has instructed the

RDFI or Gateway to return
the Entry.
R17 File Record Edit Field(s) cannot be processed RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 Some fields that are not edited
Criteria by RDFI. Non-Consumer - RDFI’s Right to Transmit by the ACH Operator are edited
Return Entries. by the RDFI.
If the Entry cannot be processed
by the RDFI, the field(s) causing
the processing error must
be identified in the Addenda
Information field of the Return.
R18 Improper The effective Entry date for ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Effective Entry a credit Entry is more than Return Non-Consumer following processing (Automatic Entry Detail
Date two Banking Days after the Rejection Criteria).
Banking Day of processing as
established by the Originating
ACH Operator; or
The effective Entry date for
a debit Entry is more than
one Banking Day after the
processing date.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

nApproved September 8, 2011, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R19 Amount Field Amount field is non-numeric. ACH Operator Reject/ Consumer or Next file delivery time No See Appendix Two, Part For ACH Operator use only.
Error Amount field is not zero in a Return Non-Consumer following processing 2.5 (Automatic Entry Detail
Prenotification, DNE, ENR, Rejection Criteria) for a full
Notification of Change, explanation of this Return
refused Notification of Reason Code.
Change, or zero dollar CCD,

2 0 1 3 O P E R AT I N G R U L E S
CTX, or IAT Entry.
Amount field is zero in
an Entry other than a
Prenotification, DNE, ENR,
Notification of Change,
Return, dishonored Return,
contested dishonored Return,
or zero dollar CCD, CTX, or
IAT Entry.
Amount field is greater than
$25,000 for ARC, BOC, POP
Entries.
R20 Non- ACH Entry to a non- RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 A non-Transaction Account. as
Transaction Transaction Account. Non-Consumer - RDFI’s Right to Transmit defined in Regulation D, would
Account Return Entries. include an account against
which transactions are prohibited
or limited.
R21 Invalid The identification number RDFI Return Non-Consumer * 2 Banking Days No Article Three, Section 3.8 This Return Reason Code
Company used in the Company - RDFI’s Right to Transmit is generally used on CIE
Identification Identification Field is not Return Entries. transactions.
valid.
R22 Invalid The Receiver has indicated RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 In CIE and MTE Entries, the
Individual ID to the RDFI that the number Non-Consumer - RDFI’s Right to Transmit Individual ID Number is used
Number with which the Originator was Return Entries. by the Receiver to identify the
identified is not correct. account.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR131
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR132
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R23 Credit Entry Any credit Entry that is RDFI Return Consumer or RDFI must transmit No Article Three, Subsection Examples:
Refused by refused by the Receiver may Non-Consumer the Return Entry to 3.8.3.2 - Timing Requirements (1) a minimum amount required
Receiver be returned by the RDFI. the ACH Operator by for Credit Entries Refused by by the Receiver has not been
the ACH Operator’s Receiver. remitted;
deposit deadline for
(2) the exact amount required
the Return Entry to
has not been remitted;
be made available
to the ODFI no later (3) the account is subject to
than the opening litigation and the Receiver will
of business on the not accept the transaction;
(4) acceptance of the transaction
APPENDIX FOUR – Return Entries

second Banking Day

following the RDFI’s results in an overpayment;
receipt of notification (5) the Originator is not known
of refusal of the Entry by the Receiver; or
from its Receiver. (6) the Receiver has not
authorized this credit Entry to
this account.
R24 Duplicate Entry The RDFI has received what RDFI Return Consumer or * 2 Banking Days No Article Three, Section 3.8 The RDFI should use this code
appears to be a duplicate Non-Consumer - RDFI’s Right to Transmit with extreme care and should
Entry; i.e., the trace number, Return Entries. be aware that if a file has been
date, dollar amount and/or duplicated, the Originator may
other data matches another have already generated a
transaction. reversal transaction to handle
the situation.
R25 Addenda Error Addenda Record Indicator ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
value is incorrect. Return Non-Consumer following processing (Automatic Entry Detail
Addenda Type Code is Rejection Criteria).
invalid, out of sequence, or
missing,
Number of Addenda Records
exceeds allowable maximum,
Addenda Sequence Number
is invalid.
R26 Mandatory Field Erroneous data or missing ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Error data in a mandatory field. Return Non-Consumer following processing (Automatic Entry Detail
Rejection Criteria).
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R27 Trace Number Original Entry Trace Number ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Error is not present in the Addenda Return Non-Consumer following processing (Automatic Entry Detail
Record on a Return or Rejection Criteria).
Notification of Change
Entry; or
Trace Number of an Addenda

2 0 1 3 O P E R AT I N G R U L E S
Record is not the same
as the Trace Number of
the preceding Entry Detail
Record.
R28 Routing The Check digit for a routing ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Number Check number is not valid. Return Non-Consumer following processing (Automatic Entry Detail
Digit Error Rejection Criteria).
R29 Corporate The RDFI has been RDFI Return Non-Consumer * 2 Banking Days No Article Three, Section 3.8 Beyond the return time frame the
Customer notified by the Receiver - RDFI’s Right to Transmit ODFI may agree to accept a late
Advises Not (non-consumer) that a Return Entries. Return Entry; if so use R31.
Authorized specific Entry has not been Article Three, Subsection
authorized by the Receiver. 3.12.1 - Unauthorized Debit
Entry
R30 RDFI Not The RDFI does not ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Participant participate in a Check Return Non-Consumer following processing (Automatic Entry Detail
in Check truncation program. Rejection Criteria).
Truncation Aricle Four, Subsection 4.2.6
Program - Return and Rejection of TRC
Entries or TRX Entries.
R31 Permissible The RDFI may return a CCD RDFI Return Non-Consumer Not defined, No Article Three, Subsection CCD and CTX Entries only.
Return Entry or CTX Entry that the ODFI determined by the 3.8.3.5 - Late Return Entries
(CCD and CTX agrees to accept. ODFI and RDFI. for CCD or CTX Entries with
only) ODFI Agreement.
R32 RDFI Non- The RDFI is not able to settle ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Settlement the Entry. Return Non-Consumer following processing (Automatic Entry Detail
Rejection Criteria).
R33 Return of XCK This Return Reason Code RDFI Extended Consumer or ** 60 Calendar Days No Article Three, Subsection
Entry may only be used to return Return Non-Consumer 3.8.3.4 - Timing Requirements
XCK Entries and is at the for Return of XCK Entries.
RDFI’s sole discretion.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR133
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR134
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R34 Limited The RDFI’s participation has ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Participation been limited by a federal or Return Non-Consumer following processing (Automatic Entry Detail
DFI state supervisor. Rejection Criteria).
R35 Return of Debit Entries (with the ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
Improper Debit exception of Reversing Return Non-Consumer following processing (Automatic Entry Detail
Entry Entries) are not permitted Rejection Criteria)
for CIE Entries or to loan
accounts.
R36 Return of ACH credit Entries (with ACH Operator Reject/ Consumer or Next file delivery time No Appendix Two, Part 2.5 For ACH Operator use only.
APPENDIX FOUR – Return Entries

Improper Credit the exception of Reversing Return Non-Consumer following processing (Automatic Entry Detail
Entry Entries) are not permitted for Rejection Criteria).
use with ARC, BOC, POP,
RCK, TEL, WEB, and XCK.
R37 Source The source document to RDFI Extended Consumer or ** 60 Calendar Days Yes Article Three, Subsection For use with ARC, BOC, and
Document which an ARC, BOC, or Return Non-Consumer 3.12.2 - Improper ARC, BOC, POP Entries only.
Presented for POP Entry relates has been POP, and RCK Debit Entries.
Payment presented for payment. Article Three, Section 3.13
- RDFI Right to Transmit
Extended Return Entries
R38 Stop Payment The RDFI determines a RDFI Extended Consumer or ** 60 Calendar Days No Article Three, Subsection For use with ARC and BOC
on Source stop payment order has Return Non-Consumer 3.11.2.2 - RDFI Obligation to Entries only.
Document been placed on the source Recredit for ARC, BOC, and
document to which the ARC RCK Entries Regarding Stop
or BOC Entry relates. Payments Orders.
Article Three, Section 3.13
- RDFI Right to Transmit
Extended Return Entries.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R39 Improper The RDFI determines that: RDFI Return Consumer or * 2 Banking Days No ArticleThree, Subsection For use with ARC, BOC, and
Source (1) the source document Non-Consumer 3.12.2 - Improper ARC, BOC, POP Entries only and when the
Document/ used for an ARC, BOC, or POP, and RCK Debit Entries. RDFI (rather than the Receiver)
Source POP Entry to its Receiver’s Article Eight, Section 8.32 - determines the Entry is improper.
Document account is improper, or Eligible Source Document.
Presented for
(2) an ARC, BOC, or POP
Payment

2 0 1 3 O P E R AT I N G R U L E S
Entry and the source
document to which the Entry
relates have both been
presented for payment and
posted to the Receiver’s
account.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR135
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR136
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

RETURN REASON CODES TO BE USED BY FEDERAL GOVERNMENT AGENCIES RETURNING ENR ENTRIES

R40 Return of This Return Reason Code Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
ENR Entry may only be used to return Government Only treas.gov/greenbook use only.
by Federal ENR Entries and is at Agency
Government the Federal Government
Agency Agency’s sole discretion.
R41 Invalid Either the Transaction Code Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Transaction included in Field 3 of the Government Only treas.gov/greenbook use only.
APPENDIX FOUR – Return Entries

Code Addenda Record does not Agency Appendix Three - ACH Record Example: Transaction Code
conform to the ACH Record Format Specifications, Part “28,” Prenotification of Demand
Format Specifications 3.2 - Glossary of ACH Record Deposit Debit Authorization, for
contained in Appendix Format Data Elements - an ENR sent to SSA pertaining
Three (ACH Record Format Payment Related Information to a direct deposit enrollment.
Specifications) or it is not
appropriate with regard to an
Automated Enrollment Entry.
R42 Routing The Routing Number and the Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Number/Check Check Digit included in Field Government Only treas.gov/greenbook use only.
Digit Error 3 of the Addenda Record is Agency
either not a valid number or
it does not conform to the
Modulus 10 formula.
R43 Invalid DFI The Receiver’s account Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Account number included in Field Government Only treas.gov/greenbook use only.
Number 3 of the Addenda Record Agency
must include at least one
alphameric character.
R44 Invalid The Individual ID Number/ Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Individual Identification Number Government Only treas.gov/greenbook use only.
ID Number/ provided in Field 3 of the Agency
Identification Addenda Record does not
Number match a corresponding
ID number in the Federal
Government Agency’s
records.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R45 Invalid The name of the consumer Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Individual or company provided in Field Government Only treas.gov/greenbook. use only.
Name/Company 3 of the Addenda Record Agency
Name either does not match a
corresponding name in
the Federal Government

2 0 1 3 O P E R AT I N G R U L E S
Agency’s records or fails
to include at least one
alphameric character.
R46 Invalid The Representative Payee Federal Return - ENR N/A N/A No The Green Book www.fms. Examples: The Representative
Representative Indicator Code included Government Only treas.gov/greenbook Payee Indicator Code is “zero,”
Payee Indicator in Field 3 of the Addenda Agency and Social Security’s records
Record has been omitted indicate that payments should
or it is not consistent with be sent to a representative
the Federal Government payee on behalf of an
Agency’s records. entitled beneficiary; or The
Representative Payee Indicator
Code is “one,” and Social
Security’s records indicate that
there is no representative payee
and the beneficiary may receive
payments directly.
For Federal Government Agency
use only.
R47 Duplicate The Entry is a duplicate of an Federal Return - ENR N/A N/A No The Green Book www.fms. For Federal Government Agency
Enrollment Automated Enrollment Entry Government Only treas.gov/greenbook use only.
previously initiated by a DFI. Agency
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR137
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR138
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

CODES TO BE USED FOR RETURN OF RCK ENTRIES

R50 State Law The RDFI is located in a RDFI Return Consumer * 2 Banking Days No Uniform Commercial Code For use with RCK Entries only.
Affecting RCK state that has not adopted Article 4
Acceptance Revised Article 4 of the http://www.law.cornell.edu/
Uniform Commercial Code ucc/4/
(1990 Official Text) and has
not revised its customer
agreements to allow for
Electronic presentment.
APPENDIX FOUR – Return Entries

OR
The RDFI is located within
a state that requires all
canceled Checks to a specific
type of account to be returned
to the Receiver within the
periodic statement.
R51 Item Related An RCK Entry considered to RDFI Extended Consumer ** 60 Calendar Days Yes Article Three, Subsection For use with RCK Entries only.
to RCK Entry be ineligible or improper. Return 3.12.2 - Improper ARC, BOC,
is Ineligible or POP, and RCK Debit Entries.
RCK Entry is Article Two, Subsection
Improper. 2.5.13.3 - RCK Eligible Items.
Article Two, Subsection
2.5.13.4 - RCK Ineligible Items.
R52 Stop Payment A stop payment order has RDFI Extended Consumer ** 60 Calendar Days No Article Three, Subsection For use with RCK Entries only.
on Item Related been placed on the item to Return 3.11.2.2 - RDFI Obligation to
to RCK Entry which the RCK Entry relates. Recredit for ARC, BOC, and
RCK Entries Regarding Stop
Payment Orders.
R53 Item and RCK In addition to an RCK Entry, RDFI Extended Consumer ** 60 Calendar Days Yes Article Three, Subsection For use with RCK Entries only.
Entry Presented the item to which the RCK Return 3.12.2 - Improper ARC, BOC,
for Payment Entry relates has also been POP, and RCK Debit Entries.
presented for payment.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

CODES TO BE USED BY THE ODFI FOR DISHONORED RETURN ENTRIES

R61 Misrouted The financial institution ODFI Dishonored Consumer or The ODFI must No Article Two, Subsection May be used for all Entries
Return preparing the Return Entry Return Non-Consumer transmit a 2.12.5.1 - Dishonor of Return except IAT.
(the RDFI of the original May be used dishonored Return by ODFI.
Entry) has placed the Entry to its ACH

2 0 1 3 O P E R AT I N G R U L E S
for all Entries
incorrect Routing Number except IAT. Operator within five
in the Receiving DFI Banking Days after
Identification field. the Settlement Date
of the Return Entry.
R67 Duplicate The ODFI has received more ODFI Dishonored Consumer or The ODFI must No Article Two, Subsection May be used for all Entries
Return than one Return for the same Return Non-Consumer transmit a 2.12.5.1 - Dishonor of Return except IAT.
Entry. May be used dishonored Return by ODFI.
for all Entries Entry to its ACH
except IAT. Operator within five
Banking Days after
the Settlement Date
of the Return Entry.
R68 Untimely Return The Return Entry has ODFI Dishonored Consumer or The ODFI must No Article Two, Subsection May be used for all Entries
not been sent within the Return Non-Consumer transmit a 2.12.5.1 - Dishonor of Return except IAT.
timeframe established by May be used dishonored Return by ODFI.
these Rules. for all Entries Entry to its ACH
except IAT. Operator within five
Banking Days after
the Settlement Date
of the Return Entry.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR139
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR140
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R69 Field Error(s) One or more of the field ODFI Dishonored Consumer or The ODFI must No Article Two, Subsection The ODFI must insert the
requirements are incorrect. Return Non-Consumer transmit a 2.12.5.1 - Dishonor of Return appropriate code(s) from below,
May be used dishonored Return by ODFI. separated by an asterisk (*),
for all Entries Entry to its ACH within the Addenda Information
except IAT. Operator within five Field of the Addenda Record
Banking Days after Format for dishonored Returns
the Settlement Date to indicate the field(s) in which
of the Return Entry. the errors occur.
01—Return Contains Incorrect
DFI Account Number
APPENDIX FOUR – Return Entries

02—Return Contains Incorrect

Original Entry Trace Number
03—Return Contains Incorrect
Dollar Amount
04—Return Contains Incorrect
Individual Identification Number/
Identification Number
05—Return Contains Incorrect
Transaction Code
06—Return Contains Incorrect
Company Identification Number
07—Return Contains an Invalid
Effective Entry Date
For Example: 01*03*06
May be used for all Entries
except IAT.
R70 Permissible The ODFI has received a ODFI Dishonored Consumer or The ODFI must No Article Two, Subsection This code may be used only
Return Entry Return Entry identified by Return Non-Consumer transmit a 2.12.5.1 - Dishonor of Return to dishonor Return Entries
Not Accepted/ the RDFI as being returned May be used dishonored Return by ODFI. containing Return Reason
Return Not with the permission of, or at for all Entries Entry to its ACH Codes R06 and R31.
Requested by the request of, the ODFI, but except IAT. Operator within five May be used for all Entries
ODFI the ODFI has not agreed to Banking Days after except IAT.
accept the Entry or has not the Settlement Date
requested the return of the of the Return Entry.
Entry.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

CODES TO BE USED BY THE RDFI FOR CONTESTED DISHONORED RETURN ENTRIES

R71 Misrouted The financial institution RDFI Contested Consumer or The contested No Article Three, Subsection May be used for all Entries
Dishonored preparing the dishonored Dishonored Non-Consumer dishonored Return 3.8.5.2 - RDFI May Contest except IAT.
Return Return Entry (the ODFI Return Entry must be Dishonored Returns.
of the original Entry) has transmitted to the

2 0 1 3 O P E R AT I N G R U L E S
May be used
placed the incorrect Routing for all Entries ACH Operator within
Number in the Receiving DFI except IAT. two Banking Days
Identification field. after the Settlement
Date of the
dishonored Return
Entry.
R72 Untimely The dishonored Return Entry RDFI Contested Consumer or The contested No Article Two, Subsection May be used for all Entries
Dishonored has not been sent within the Dishonored Non-Consumer dishonored Return 2.12.5.1 - Dishonor of Return except IAT.
Return designated timeframe. Return Entry must be by ODFI.
May be used transmitted to the Article Three, Subsection
for all Entries ACH Operator within 3.8.5.2 - RDFI May Contest
except IAT. two Banking Days Dishonored Returns.
after the Settlement
Date of the
dishonored Return
Entry.
R73 Timely Original The RDFI is certifying that RDFI Contested Consumer or The contested No Article Three, Subsection May be used for all Entries
Return the original Return Entry was Dishonored Non-Consumer dishonored Return 3.8.5.2 - RDFI May Contest except IAT.
sent within the timeframe Return Entry must be Dishonored Returns.
designated in these Rules. May be used transmitted to the
for all Entries ACH Operator within
except IAT. two Banking Days
after the Settlement
Date of the
dishonored Return
Entry.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR141
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR142
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R74 Corrected The RDFI is correcting a RDFI Corrected Consumer or The corrected No Article Three, Subsection Data must be obtained from the
Return previous Return Entry that Return Non-Consumer Return Entry must 3.8.5.1 - RDFI May Correct following fields in the original
was dishonored using Return May be used be transmitted to Dishonored Returns. Company Batch Header Record,
Reason Code R69 (Field for all Entries the ACH Operator Entry Detail Record or Addenda
Errors) because it contained except IAT. within two Banking Record:
incomplete or incorrect Days after the • DFI Account Number
information. Settlement Date • Trace Number
of the dishonored • Amount
Return Entry. • Individual Identification Number/
Identification Number
APPENDIX FOUR – Return Entries

• Transaction Code
• Company Identification
• Effective Entry Date
May be used for all Entries
except IAT.
R75 Return Not a The Return Entry was not RDFI Contested Consumer or The contested No Article Three, Subsection This code may be used by the
Duplicate a duplicate of an Entry Dishonored Non-Consumer dishonored Return 3.8.5.2 - RDFI May Contest RDFI to contest a dishonored
previously returned by the Return Entry must be Dishonored Returns. Return Entry from an ODFI that
RDFI. May be used transmitted to the used Return Reason Code R67
for all Entries ACH Operator within (Duplicate Return).
except IAT. two Banking Days May be used for all Entries
after the Settlement except IAT.
Date of the
dishonored Return
Entry.
R76 No Errors The original Return Entry RDFI Contested Consumer or The contested No Article Three, Subsection This code may be used by the
Found did not contain the errors Dishonored Non-Consumer dishonored Return 3.8.5.2 - RDFI May Contest RDFI to contest a dishonored
indicated by the ODFI in the Return Entry must be Dishonored Returns. Return Entry from an ODFI that
dishonored Return Entry. May be used transmitted to the used Return Reason Code R69
for all Entries ACH Operator within (Field Errors).
except IAT. two Banking Days May be used for all Entries
after the Settlement except IAT.
Date of the
dishonored Return
Entry.
 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

CODES TO BE USED BY GATEWAYS FOR THE RETURN OF INTERNATIONAL PAYMENTS

R80 IAT Entry The IAT Entry is being Gateway Return Consumer or * 2 Banking Days No Article Three, Section 3.8 For Gateway use with Outbound
Coding Error returned due to one or more Non-Consumer - RDFI’s Right to Transmit IAT Entries only
of the following conditions: Return Entries.
• invalid DFI/Bank Branch

2 0 1 3 O P E R AT I N G R U L E S
Article Five, Section 5.3 -
Country Code Gateway Assumes Obligations
• invalid DFI/Bank of Other Participants.
Identification Number
Qualifier
• invalid Foreign Exchange
Indicator
• invalid ISO Originating
Currency Code
• invalid ISO Destination
Currency Code
• invalid ISO Destination
Country Code
• invalid Transaction Type
Code.
R81 Non-Participant The IAT Entry is being Gateway Return Consumer or * 2 Banking Days No Article Five, Subsection For Gateway use with Outbound
in IAT Program returned because the Non-Consumer 5.1.1 - Gateway Must Enter IAT Entries only
Gateway does not have Agreement with ODFI or
an agreement with either Gateway’s customer.
the ODFI or the Gateway’s
customer to transmit IAT
Entries.

 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

OR143
APPENDIX FOUR – Return Entries
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN

OR144
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED
R82 Invalid Foreign The reference used to identify Gateway Return Consumer or * 2 Banking Days No For Gateway use with Outbound
Receiving DFI the Foreign Receiving DFI Non-Consumer IAT Entries only
Identification of an Outbound IAT Entry is
invalid.
R83 Foreign The IAT Entry is being Gateway Return Consumer or * 2 Banking Days No For Gateway use with Outbound
Receiving DFI returned due to settlement Non-Consumer IAT entries only.
Unable to Settle problems in the foreign
payment system.
R84 Entry Not For Outbound IAT Entries, the Gateway Return Consumer or * 2 Banking Days No For Gateway use with Outbound
Processed by
APPENDIX FOUR – Return Entries

Entry has not been processed Non-Consumer IAT entries only.

Gateway and is being returned at the
Gateway’s discretion because
either (1) the processing of
such Entry may expose the
Gateway to excessive risk,
or (2) the foreign payment
system does not support the
functions needed to process
the transaction.

 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

2 0 1 3 O P E R AT I N G R U L E S
 PART 4.2  Table of Return Reason Codes (continued)
WRITTEN
INITIATED RETURN ACCOUNT TIME CROSS
CODE TITLE DESCRIPTION STATEMENT NOTES
BY TYPE TYPE FRAME REFERENCE
REQUIRED

n
R85 Incorrectly The RDFI/Gateway has Gateway Return Consumer or * 2 Banking Days No For Gateway use with Entries
Coded identified the Entry as an Non-Consumer bearing an SEC Code other
Outbound Outbound international than IAT.
International payment and is returning
Payment the Entry because it bears
an SEC Code that lacks

2 0 1 3 O P E R AT I N G R U L E S
information required
by the Gateway for OFAC
compliance.

 * E ach Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the second
Banking Day following the Settlement Date of the original Entry.
** Each Return Entry must be received by the RDFI’s ACH Operator by its deposit deadline for the Return Entry to be made available to the ODFI no later than the opening of business on the Banking
Day following the sixtieth calendar day following the Settlement Date of the original Entry.

nApproved September 8, 2011, Effective March 15, 2013

OR145
APPENDIX FOUR – Return Entries
APPENDIX FOUR – Return Entries

PART 4.3   Record Formats for Return

Entries
Unless otherwise noted, the field contents for
Return Entries must match the field contents of
the original Entries. [See Appendix Three (ACH
Record Format Specifications) for the File Header,
Company/Batch Control and File Control Record
formats.]

OR146 2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.3.1  Company/Batch Header Record Format for Returns

RETURNS — COMPANY/BATCH HEADER RECORD

(excludes IAT entries)

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD COMPANY STANDARD COMPANY COMPANY EFFECTIVE SETTLEMENT

ELEMENT TYPE SERVICE COMPANY DISCRETIONARY COMPANY ENTRY CLASS ENTRY DESCRIPTIVE ENTRY DATE ORIGINATOR ORIGINATING DFI BATCH

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CLASS CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) STATUS CODE IDENTIFICATION NUMBER

Field
Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric1 Alphameric YYMMDD Numeric Alphameric2 TTTTAAAA3 Numeric4

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Return Entries, each field of the Company/Batch Header remains unchanged from the original entry, unless otherwise noted.
1  May contain the identification of the ACH Operator converting the entry.
2  Changed to reflect the Originator Status Code of the institution initiating the Return Entry (i.e., the RDFI of the original entry).
3  Changed to reflect the Routing Number of the institution initiating the Return Entry (i.e., the RDFI of the original entry).
4  Changed to the batch number assigned by the institution preparing the Automated Return Entry.

OR147
APPENDIX FOUR – Return Entries
 SUBPART 4.3.2  Company/Batch Header Record Formats for International ACH Transaction (IAT) Returns

OR148
IAT RETURNS — COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
GO
FOREIGN ISO STANDARD ISO ISO IDENTIFICATION/
DATA RECORD SERVICE FOREIGN EXCHANGE FOREIGN DESTINATION ENTRY COMPANY ORIGINATING DESTINATION EFFECTIVE SETTLEMENT ORIGINATOR ORIGINATING
ELEMENT TYPE CLASS IAT EXCHANGE REFERENCE EXCHANGE COUNTRY ORIGINATOR CLASS ENTRY CURRENCY CURRENCY ENTRY DATE STATUS DFI BATCH
NAME CODE CODE INDICATOR INDICATOR INDICATOR REFERENCE CODE IDENTIFICATION CODE DESCRIPTION CODE CODE DATE (JULIAN) CODE IDENTIFICATION NUMBER
Field
Inserted by
Inclusion M M O M R R M M M M M M R M M M
ACH Operator
Requirement
1 2 3 4
Contents ‘5’ Numeric Alphameric Alphameric Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric TTTTAAAA Numeric

Length 1 3 16 2 1 15 2 10 3 10 3 3 6 3 1 8 7
APPENDIX FOUR – Return Entries

Position 01-01 02-04 05-20 21-22 23-23 24-38 39-40 41-50 51-53 54-63 64-66 67-69 70-75 76-78 79-79 80-87 88-94

NOTE: For IAT Return Entries, each field of the Company/Batch Header Record remains unchanged from the original entry, unless otherwise noted.
1 For the return of an outbound International ACH Transaction originated by a U.S. ODFI, this field will contain the foreign exchange rate that is applicable at the time of the return entry if a foreign
exchange rate is provided within this field on the forward entry.
2  Changed to reflect the Originator Status Code of the institution initiating the Return Entry (i.e., the RDFI of the original entry).
3  Changed to reflect the Routing Number of the institution initiating the Return Entry (i.e., the RDFI of the original entry).
4  Changed to the batch number assigned by the institution preparing the Automated Return Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.3.3 Corporate Entry Detail Record Format for Returns

RETURNS — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O M R N/A R M M

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric ‘1’ Numeric4

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

NOTE: For Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the institution receiving the Return Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  Changed to the Trace Number assigned by the institution preparing the Automated Return Entry.

OR149
APPENDIX FOUR – Return Entries
 SUBPART 4.3.4  Entry Detail Record Format for Returns

OR150
RETURNS ­— ENTRY DETAIL RECORD
(excludes IAT entries)

FIELD 1 2 3 4 5 6 7 8 9 10 11

INDIVIDUAL
INDIVIDUAL NAME/ DISCRETIONARY DATA/
DATA RECORD DFI IDENTIFICATION NUMBER/ RECEIVING PAYMENT TYPE CODE/ ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT IDENTIFICATION NUMBER/ COMPANY CARD TRANSACTION RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT CHECK SERIAL NUMBER NAME TYPE CODE INDICATOR NUMBER

Field
Inclusion
APPENDIX FOUR – Return Entries

M M M M R M O R R/M M M
Requirement

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Alphameric $$$$$$$$¢¢4 Alphameric5 Alphameric5 Alphameric6 ‘1’ Numeric7

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

NOTE: For Return Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2 Changed to the Routing Number of the institution receiving the Return Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4 For the return of an outbound International ACH Transactions entry originated by a U.S. ODFI, this amount will be different from the amount reflected in the original forward entry if the exchange rate is
different at the time of the return.
5 For CIE and MTE entries, positions 40-54 are used for a 15-character Individual Name, and positions 55-76 are used for a 22-character Individual Identification Number.
6   For SHR and POS return entries, this field (positions 77-78) is mandatory and contains the Card Transaction Type Code (positions 77-78) of the original entry.
7  Changed to the Trace Number assigned by the institution preparing the Automated Return Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.3.5  Addenda Record Format for Returns
(Note: This format is not for use with IAT Returns.)

RETURNS — ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

DATA
ELEMENT RECORD TYPE ADDENDA TYPE RETURN REASON ORIGINAL ENTRY ORIGINAL RECEIVING ADDENDA

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE CODE TRACE NUMBER DATE OF DEATH DFI IDENTIFICATION INFORMATION TRACE NUMBER

Field
Inclusion
Requirement M M M M O R O M

Contents ‘7’ ‘99’ Alphameric Numeric1 YYMMDD2 TTTTAAAA3 Alphameric Numeric

Length 1 2 3 15 6 8 44 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-79 80-94

1  Copy data from positions 80-94 of the Entry Detail Record

2  To be used only with Return Code R14 or R15.
3  Copy data from positions 04-11 of the original Entry Detail Record.

OR151
APPENDIX FOUR – Return Entries
 SUBPART 4.3.6  Entry Detail Record for IAT Return Entries

OR152
IAT RETURNS — ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

FOREIGN
RECEIVER’S GATEWAY
GO NUMBER ACCOUNT OPERATOR SECONDARY
DATA RECORD IDENTIFICATION/ OF NUMBER/ OFAC OFAC ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ADDENDA DFI ACCOUNT SCREENING SCREENING RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT RECORDS RESERVED AMOUNT NUMBER RESERVED INDICATOR INDICATOR INDICATOR NUMBER

Field
Inclusion M M M M M N/A M M N/A O O M M
APPENDIX FOUR – Return Entries

Requirement

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Numeric Blank $$$$$$$$¢¢4 Alphameric Blank Alphameric Alphameric Numeric Numeric5
Length 1 2 8 1 4 13 10 35 2 1 1 1 15

Position 01-01 02-03 04-11 12-12 13-16 17-29 30-39 40-74 75-76 77-77 78-78 79-79 80-94

NOTE: For IAT Return Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate Return Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the institution receiving the Return Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4 For the return of an outbound International ACH Transaction originated by a U.S. ODFI, this amount will be different from the amount reflected in the original forward entry
if the exchange rate is different at the time of the return.
5  Changed to the Trace Number assigned by the institution preparing the Automated Return Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.3.6 Entry Detail Addenda Records for IAT Return Entries (continued)

FIRST ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6 7 8

ENTRY
DATA RECEIVING COMPANY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE TRANSACTION TYPE FOREIGN PAYMENT FOREIGN TRACE NAME/ SEQUENCE
NAME CODE CODE CODE AMOUNT NUMBER INDIVIDUAL NAME RESERVED NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion M M R R O M N/A M
Requirement

Contents ‘7’ ‘10’ Alphameric $$$$$$$$$$$$$$$$¢¢ Alphameric Alphameric Blank Numeric1

Length 1 2 3 18 22 35 6 7

Position 01-01 02-03 04-06 07-24 25-46 47-81 82-87 88-94

NOTE: For IAT Return Entries, each field of the 1st Addenda Record remains unchanged from the original 1st Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

SECOND ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6

DATA RECORD ENTRY DETAIL

ELEMENT TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE NAME STREET ADDRESS RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘11’ Alphameric Alphameric Blank Numeric1

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

NOTE: For IAT Return Entries, each field of the 2nd Addenda Record remains unchanged from the original 2nd Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

OR153
APPENDIX FOUR – Return Entries
 SUBPART 4.3.6  Entry Detail Addenda Records for IAT Return Entries continued)

OR154
THIRD ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE COUNTRY & POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘12’ Alphameric Alphameric Blank Numeric 1

APPENDIX FOUR – Return Entries

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

NOTE: For IAT Return Entries, each field of the 3rd Addenda Record remains unchanged from the original 3rd Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

FOURTH ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6 7 8

ORIGINATING DFI
DATA IDENTIFICATION ORIGINATING ORIGINATING ENTRY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATING NUMBER DFI DFI BRANCH SEQUENCE
NAME CODE CODE DFI NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘13’ Alphameric Alphameric Alphameric Alphameric Blank Numeric1

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

NOTE: For IAT Return Entries, each field of the 4th Addenda Record remains unchanged from the original 4th Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.3.6  Entry Detail Addenda Records for IAT Return Entries (continued)

FIFTH ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6 7 8

RECEIVING ENTRY
DATA RECEIVING DFI IDENTIFICATION RECEIVING DFI DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE DFI NUMBER RECEIVING DFI BRANCH SEQUENCE
NAME CODE CODE NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘14’ Alphameric Alphameric Alphameric Alphameric Blank Numeric1

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

NOTE: For IAT Return Entries, each field of the 5th Addenda Record remains unchanged from the original 5th Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

SIXTH ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6

DATA RECEIVER RECEIVER ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE IDENTIFICATION STREET SEQUENCE
NAME CODE CODE NUMBER ADDRESS RESERVED NUMBER

Field
Inclusion M M O M N/A M
Requirement

Contents ‘7’ ‘15’ Alphameric Alphameric Blank Numeric1

Length 1 2 15 35 34 7

Position 01-01 02-03 04-18 19-53 54-87 88-94

NOTE: For IAT Return Entries, each field of the 6th Addenda Record remains unchanged from the original 6th Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

OR155
APPENDIX FOUR – Return Entries
 SUBPART 4.3.6  Entry Detail Addenda Records for IAT Return Entries (continued)

OR156
SEVENTH ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6

DATA RECEIVER ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE RECEIVER COUNTRY & SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘16’ Alphameric Alphameric Blank Numeric 1

APPENDIX FOUR – Return Entries

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

NOTE: For IAT Return Entries, each field of the 7th Addenda Record remains unchanged from the original 7th Addenda Record, unless otherwise noted.
1  Changed to reflect the Entry Detail Sequence Number associated with the trace number assigned by the institution preparing the Automated Return Entry.

EIGHTH ADDENDA RECORD FOR IAT RETURN ENTRIES

FIELD 1 2 3 4 5 6 7 8 9

DATA ORIGINAL ORIGINAL

ELEMENT RECORD TYPE ADDENDA TYPE RETURN REASON ORIGINAL ENTRY DATE OF RECEIVING DFI FORWARD ENTRY ADDENDA TRACE
NAME CODE CODE CODE TRACE NUMBER DEATH IDENTIFICATION PAYMENT AMOUNT INFORMATION NUMBER

Field
Inclusion M M M M O R R O M
Requirement

Contents ‘7’ ‘99’ Alphameric Numeric1 YYMMDD2 TTTTAAAA3 $$$$$$$$¢¢4 Alphameric Numeric

Length 1 2 3 15 6 8 10 34 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-45 46-79 80-94

1  Copy data from positions 80-94 of the Entry Detail Record.

2  To be used only with Return Reason Code R14 or R15.
3  Copy data from positions 04-11 of the original Entry Detail Record.
4  Copy data from positions 30-39 of the original Entry Detail Record.

2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX FOUR – Return Entries

PART 4.4  Dishonored Return Entries • Addenda Type Code “99” must be used to
indicate that the Addenda Record contains
The following specifications apply to dishonored
return information.
Return Entries:
• The following fields of the Addenda Record
• Each dishonored Return Entry that is
must be filled when originating a dishonored
initiated by an ODFI must be in the format
Return Entry:
and sequence defined within this Appendix
Four.
– Positions 39 - 53  Return Trace Number
• Terms used in the format have the meanings
– Positions 54 - 56  Return Settlement Date
defined in Appendix Three (ACH Record
Format Specifications).
– Positions 57 - 58  Return Reason Code
• The Transaction Code used in the Entry
The initiation of a dishonored Return Entry with
Detail Record must be:
Return Reason Code R68 constitutes a certification
by the ODFI that the Return was untimely.
– 21 or 26 for Demand Accounts,

– 31 or 36 for Savings Accounts,

– 41 or 46 for General Ledger Accounts, or

– 51 or 56 for Loan Accounts.

2 0 1 3 O P E R AT I N G R U L E S OR157
 SUBPART 4.4.1 Company/Batch Header Record Format for Dishonored Return
(excludes IAT Entries)

OR158
DISHONORED RETURNS — COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD SERVICE COMPANY STANDARD COMPANY COMPANY EFFECTIVE SETTLEMENT ORIGINATOR
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY ENTRY CLASS ENTRY DESCRIPTIVE ENTRY DATE STATUS ORIGINATING DFI BATCH
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) CODE IDENTIFICATION NUMBER

Field Inclusion Inserted by ACH

Requirement M M M O M M M O R Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric1 TTTTAAAA2 Numeric3
APPENDIX FOUR – Return Entries

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Dishonored Return Entries, each field of the Company/Batch Header Record remains unchanged from the Return Entry, unless otherwise noted.
1  Changed to reflect the Originator Status Code of the institution initiating the Dishonored Return Entry (i.e., the RDFI of the Return Entry).
2  Changed to reflect the Routing Number of the institution initiating the Dishonored Return Entry (i.e., the RDFI of the Return Entry).
3  Changed to a Batch Number assigned by the institution preparing the Dishonored Return Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.4.2  Corporate Entry Detail Record Format for Dishonored Returns

DISHONORED RETURNS — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD DFI NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M O M R N/A R M M

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

NOTE: For Dishonored Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the Return entry, unless otherwise noted.
1  Changed to the Routing Number of the institution receiving the Dishonored Return Entry (i.e., the ODFI of the Return Entry).
2  Changed to the Check Digit calculated according to NACHA Standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Dishonored Return Entry (i.e., the RDFI of the Return Entry).

OR159
APPENDIX FOUR – Return Entries
 SUBPART 4.4.3 Entry Detail Record Format for Dishonored Returns
(excludes IAT Entries)

OR160
DISHONORED RETURNS — ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DISCRETIONARY
INDIVIDUAL DATA/PAYMENT
INDIVIDUAL NAME/ TYPE CODE/
DATA RECORD DFI IDENTIFICATION NUMBER/ RECEIVING CARD ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT IDENTIFICATION NUMBER/ COMPANY TRANSACTION RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT CHECK SERIAL NUMBER NAME TYPE CODE INDICATOR NUMBER

Field
Inclusion M M M M R M O R R/M M M
APPENDIX FOUR – Return Entries

Requirement

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

NOTE: For Dishonored Return Entries, each field of the Entry Detail Record remains unchanged from the Return Entry, unless otherwise noted.
1 Changed to the Routing Number of the institution receiving the Dishonored Return Entry (i.e., the ODFI of the Return Entry).
2  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Dishonored Return Entry (i.e., the RDFI of the Return Entry).

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.4.4  Addenda Record Format for Dishonored Returns
(excludes IAT Entries)

DISHONORED RETURNS — ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12

DATA RECORD DISHONORED ORIGINAL RETURN RETURN RETURN

ELEMENT TYPE ADDENDA RETURN ORIGINAL ENTRY RECEIVING DFI TRACE SETTLEMENT REASON ADDENDA TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE TYPE CODE REASON CODE TRACE NUMBER RESERVED IDENTIFICATION RESERVED NUMBER DATE CODE INFORMATION NUMBER

Field
Inclusion
Requirement M M M M N/A R N/A M M M O/M M

Contents ‘7’ ‘99’ Alphameric Numeric1 Blank TTTTAAAA2 Blank Numeric Numeric Alphameric Alphameric3 Numeric4

Length 1 2 3 15 6 8 3 15 3 2 21 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-38 39-53 54-56 57-58 59-79 80-94

1  Copy data from positions 7-21 of the Addenda Record of the return entry.
2  Copy data from positions 28-35 of the Addenda Record of the return entry.
3 For Automated Dishonored Returns bearing Return Reason Code R69 (Field Errors) this field (positions 59-79) must contain the code(s) to indicate the field(s) in which erroneous information is located.
4  For Automated Dishonored Returns, changed to reflect the new Trace Number found in positions 80-94 of the Entry Detail Record or Corporate Entry Detail Record.

OR161
APPENDIX FOUR – Return Entries
APPENDIX FOUR – Return Entries

PART 4.5  Contested Dishonored ACH • The following fields of the Addenda Record
Return Entries must be filled when originating a contested
Dishonored Return Entry:
SUBPART 4.5.1  Contested Dishonored
Return Entries – Positions 22 – 27 D
 ate Original Entry
• Each contested dishonored Return Entry Returned
initiated by an RDFI must be in the format
and sequence set forth in this Appendix Four. – Positions 36 – 38 O
 riginal Settlement
Date ( Julian Date)
• Terms used in the format have the meanings
set forth in Appendix Three (ACH Record – Positions 39 – 53 Return Trace Number
Format Specifications).
– Positions 54 – 56 Return Settlement Date
• The initiation of a contested dishonored
Return Entry constitutes a certification by – Positions 57 – 58 Return Reason Code
the RDFI that the Entry was returned in
accordance with these Rules. – Positions 59 – 73 D
 ishonored Return
Trace Number
• The Transaction Code used in the Entry
Detail Record must be: – Positions 74 – 76 D
 ishonored Return
Settlement Date
– 21 or 26 for Demand Accounts,
– Positions 77 – 78 D
 ishonored Return
– 31 or 36 for Savings Accounts, Reason Code

– 41 or 46 for General Ledger Accounts, or SUBPART 4.5.2  Corrected Return Entries

An RDFI may generate a corrected Return by
– 51 or 56 for Loan Accounts. creating a contested dishonored Return with Return
Reason Code “R74” in accordance with the format
• Addenda Type Code “99” must be used to requirements in this Appendix Four. The corrected
indicate that the addenda record contains Return Entry must provide the correcting data.
return information.

OR162 2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.5.3  Company/Batch Header Record Format for Contested Dishonored Return
(excludes IAT Entries)

CONTESTED DISHONORED RETURN — COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

STANDARD
DATA RECORD SERVICE COMPANY ENTRY COMPANY COMPANY EFFECTIVE SETTLEMENT
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY CLASS ENTRY DESCRIPTIVE ENTRY DATE ORIGINATOR ORIGINATING DFI BATCH
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) STATUS CODE IDENTIFICATION NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric1 TTTTAAAA2 Numeric3

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Contested Dishonored Return Entries, each field of the Company/Batch Header Record remains unchanged from the Dishonored Return Entry unless, otherwise noted.
1  Changed to reflect the Originator Status Code of the institution initiating the Contested Dishonored Return Entry (i.e., the RDFI of the Dishonored Return Entry).
2  Changed to reflect the Routing Number of the institution initiating the Contested Dishonored Return Entry (i.e., the RDFI of the Dishonored Return Entry).
3  Changed to a Batch Number assigned by the institution preparing the Contested Dishonored Return Entry.

OR163
APPENDIX FOUR – Return Entries
 SUBPART 4.5.4  Corporate Entry Detail Record Format for Contested Dishonored Return

OR164
CONTESTED DISHONORED RETURNS — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD DFI NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O M R N/A R M M
APPENDIX FOUR – Return Entries

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

NOTE: For Contested Dishonored Return Entries, each field of the Corporate Entry Detail Record remains unchanged from the Dishonored Return entry, unless otherwise noted.
1  Changed to the Routing Number of the institution receiving the Contested Dishonored Return Entry (i.e., the ODFI of the Dishonored Return Entry).
2  Changed to the Check Digit calculated according to NACHA Standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Contested Dishonored Return Entry (i.e., the RDFI of the Dishonored Return Entry).

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 4.5.5 Entry Detail Record Format for Contested Dishonored Return
(excludes IAT Entries)

CONTESTED DISHONORED RETURNS ­— ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DISCRETIONARY
DATA/PAYMENT
INDIVIDUAL INDIVIDUAL NAME/ TYPE CODE/

2 0 1 3 O P E R AT I N G R U L E S
DATA RECORD DFI IDENTIFICATION NUMBER/ RECEIVING CARD ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT IDENTIFICATION NUMBER/ COMPANY TRANSACTION RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT CHECK SERIAL NUMBER NAME TYPE CODE INDICATOR NUMBER

Field
Inclusion M M M M R M O R R R/M M
Requirement

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

NOTE: F  or Contested Dishonored Return Entries, each field of the Entry Detail Record remains unchanged from the Dishonored Return Entry, unless
otherwise noted.
1 Changed to the Routing Number of the institution receiving the Contested Dishonored Return Entry (i.e., the ODFI of the Dishonored Return Entry).
2  Changed to the Check Digit calculated according to NACHA Standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Contested Dishonored Return Entry (i.e., the RDFI of the Dishonored Return Entry).

OR165
APPENDIX FOUR – Return Entries
 SUBPART 4.5.6  Addenda Record for Contested Dishonored Return
(excludes IAT Entries)

OR166
CONTESTED DISHONORED RETURNS — ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
CONTESTED
DISHONORED ORIGINAL DATE ORIGINAL DISHONORED DISHONORED DISHONORED
DATA RECORD ADDENDA RETURN ENTRY ORIGINAL ORIGINAL SETTLEMENT RETURN RETURN RETURN RETURN RETURN RETURN
ELEMENT TYPE TYPE REASON TRACE ENTRY RECEIVING DFI DATE TRACE SETTLEMENT REASON TRACE SETTLEMENT REASON TRACE
NAME CODE CODE CODE NUMBER RETURNED IDENTIFICATION (JULIAN) NUMBER DATE CODE NUMBER DATE CODE RESERVED NUMBER

Field
Inclusion
Requirement M M M M O R M M M M M M M N/A M
APPENDIX FOUR – Return Entries

Contents ‘7’ ‘99’ Alphameric Numeric1 YYMMDD2 TTTTAAAA3 Numeric2 Numeric Numeric Alphameric Numeric Numeric Alphameric Blank Numeric4

Length 1 2 3 15 6 8 3 15 3 2 15 3 2 1 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-38 39-53 54-56 57-58 59-73 74-76 77-78 79-79 80-94

1  Copy data from positions 7-21 of the Addenda Record of the Dishonored Return Entry.
2  Mandatory only if Contested Dishonored Return Reason Code is R73.
3  Copy data from positions 28-35 of the Addenda Record of the Dishonored Return Entry.
4  For Automated Contested Dishonored Returns changed to reflect the new Trace Number found in positions 80-94 of the Entry Detail Record or Corporate Entry Detail Record.

2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX FIVE – Notification of Change

– 41 or 46 for General Ledger Accounts, or

APPENDIX FIVE – 51 or 56 for Loan Accounts.

Notification of • The Amount field must be zero.

Change • Addenda Type Code 98 must be used to

indicate that the Addenda Record contains
corrected information.
A Notification of Change may be created by an
RDFI to notify the ODFI that a posted Entry or • Field 3 of the Addenda Record must contain
Prenotification Entry contains invalid or erroneous the appropriate Change Code from the
information and should be changed. Table in this Appendix Five indicating the
information to be corrected.
PART 5.1  Notification of Change
A Notification of Change must comply with the • Field 7 of the Addenda Record must contain
following specifications: the corrected information corresponding to
the Change Code used in Field 3.
• The Company/Batch Header Record, Entry
Detail Record, and Addenda Record formats PART 5.2  Refused Notification of
as defined in this Appendix Five must be Change
used.
A refused Notification of Change is created by
an ODFI to refuse a Notification of Change Entry
• The Standard Entry Class Code “COR” must be
containing incorrect or incomplete information.
used to denote a batch containing corrected
Each refused Notification of Change Entry must
information.
be in the format and sequence set forth in this
Appendix Five and must contain the reason(s) for
• The Transaction Code must be:
the refusal of the Notification of Change Entry.
– 21 or 26 for Demand Accounts,

– 31 or 36 for Savings Accounts,

2 0 1 3 O P E R AT I N G R U L E S OR167
 PART 5.3  Table of Change Codes
INITIATED CORRECTED ENTRY TIME

OR168
CODE DESCRIPTION NOTES EXAMPLES
BY DATA TYPE FRAME

CHANGE CODES FOR NOTIFICATION OF CHANGE ENTRIES

C01 Incorrect DFI Account RDFI Correct DFI Account NOC 2 Banking Days from Time frame not applicable for merger or This code would also be used when an
Number Number appears in (COR) original Entry Settlement acquisition. Account Number is incorrectly formatted.
first 17 positions of the Date IAT: For Outbound IAT entries, the correct
Corrected Data Field. Foreign Receiver’s Account Number will
appear in the first (left justification) 35
positions of the Corrected Data Field.
C02 Incorrect Routing RDFI Correct Routing Number NOC 2 Banking Days from Time frame not applicable for merger or Due to merger or consolidation, a once
Number (including Check Digit) (COR) original Entry Settlement acquisition. valid Routing Number must be changed.
appears in first nine Date IAT: For Outbound IAT entries, this field refers
positions of the Corrected to the Gateway Operator’s routing number.
Data Field.
APPENDIX FIVE – Notification of Change

C03 Incorrect Routing RDFI Correct Routing Number NOC 2 Banking Days from Time frame not applicable for merger or Due to merger or consolidation, a once
Number and Incorrect (including Check Digit) (COR) original Entry Settlement acquisition. valid Routing Number must be changed,
DFI Account Number appears in first nine Date IAT: This change code should not be used and in most instances this change will
positions of the Corrected for Outbound IAT entries due to field length cause a change to the account numbering
Data Field--correct DFI limitations. structure.
Account Number appears
in the 13th through 29th
position of same field with
a space in the 10th, 11th,
and 12th positions.
C04 Incorrect Individual RDFI Correct Individual Name/ NOC 2 Banking Days from Time frame not applicable for merger or
Name/Receiving Receiving Company (COR) original Entry Settlement acquisition.
Company Name

n
Name appears in first 22 Date IAT: For IAT Entries, the Correct
positions of the Corrected Individual Name/Receiving Company
Data Field. Name appears in the first 35 positions of
the Corrected Data Field.
C05 Incorrect Transaction RDFI Correct Transaction NOC 2 Banking Days from Time frame not applicable for merger or The account number contained in the Entry
Code Code appears in first two (COR) original Entry Settlement acquisition. is a checking account number but the Entry
positions of the Corrected Date contains a Transaction Code for a savings
Data Field. account, or the account number contained
in the Entry is a savings account number
but the Entry contains a Transaction Code
for a checking account.

nApproved September 8, 2011, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S
 PART 5.3  Table of Change Codes (continued)
INITIATED CORRECTED ENTRY TIME
CODE DESCRIPTION NOTES EXAMPLES
BY DATA TYPE FRAME
C06 Incorrect DFI Account RDFI Correct DFI Account NOC 2 Banking Days from Time frame not applicable for merger or The account number contained in the
Number and Incorrect Number appears in the (COR) original Entry Settlement acquisition. Entry is incorrect and the Transaction
Transaction Code first 17 positions of the Date IAT: This change code should not be used Code does not match the type of account,
Corrected Data Field -- for Outbound IAT entries due to field length i.e. the account number structure is a
correct Transaction Code limitations. checking account number but is not a valid
appears in the 21st and account number and the Transaction Code
22nd positions of the contained in the Entry is for a savings
same field with spaces in account.

2 0 1 3 O P E R AT I N G R U L E S
the 18th, 19th, and 20th
positions.
C07 Incorrect Routing RDFI Correct Routing Number NOC 2 Banking Days from Time frame not applicable for merger or An Entry posting to a savings account
Number, Incorrect DFI (including Check Digit) (COR) original Entry Settlement acquisition. should actually be going to a demand
Account Number, and appears in the first nine Date IAT: This change code should not be used account or vice versa, and the routing
Incorrect Transaction positions of the Corrected for Outbound IAT entries due to field length number and account number are also
Code Data Field -- correct DFI limitations. incorrect.
Account Number appears
in the 10th through 26th
positions of the same field
-- and correct Transaction
Code appears in the 27th
and 28th positions of the
same field.
C08 Incorrect Receiving DFI RDFI The correct Receiving DFI NOC 2 Banking Days from Time frame not applicable for merger or
Identification (IAT only) Identification appears in (COR) original Entry Settlement acquisition.
the first 34 positions of the Date
Corrected Data Field.
C09 Incorrect Individual RDFI Correct number appears NOC 2 Banking Days from Time frame not applicable for merger or Individual’s Identification Number within the
Identification Number in first 22 positions of the (COR) original Entry Settlement acquisition. Company is incorrect, either on initial input

n
Incorrect Individual Corrected Data Field. Date IAT: For IAT Entries, the correct Receiver or through merger or consolidation.
Identification Number/ Identification Number appears in the first
Incorrect Receiver 15 positions of the Corrected Data Field.
Identification Number

nApproved September 8, 2011, Effective March 15, 2013

OR169
APPENDIX FIVE – Notification of Change
 PART 5.3  Table of Change Codes (continued)
INITIATED CORRECTED ENTRY TIME

OR170
CODE DESCRIPTION NOTES EXAMPLES
BY DATA TYPE FRAME
C13 Addenda Format Error RDFI Information in the Entry NOC 2 Banking Days from Time frame not applicable for merger or A CCD Entry is received with an “05”
Detail Record was correct (COR) original Entry Settlement acquisition. Addenda Type Code, but the addenda
and the Entry was able to Date information does not contain payment
be processed and posted related ANSI ASC X12 data segments or
by the RDFI. However, NACHA endorsed banking conventions.
information found in the
Addenda Record was
unclear or was formatted
incorrectly.

n
C14 Incorrect SEC Code Gateway The RDFI/Gateway NOC 2 Banking Days This Change Code may only be used by a A CCD or PPD Entry is received by the
for Outbound has identified the (COR) from original Entry Gateway to request a change to the IAT RDFI and is posted to the Receiver’s
International Payment Entry as an Outbound Settlement Date format. It may not be used by RDFIs to account, but the Receiver has also
international payment request other changes involving the use of placed a standing instruction with
and is requesting Standard Entry Class Codes. the RDFI to forward all funds from
that future Entries the entry to the Receiver’s account in
APPENDIX FIVE – Notification of Change

be identified as IAT another country.

Entries and convey
information required
by the Gateway for
OFAC compliance.
The value “IAT” must
appear within the
first 3 positions of the
Corrected Data Field

nApproved September 8, 2011, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S
 PART 5.3  Table of Change Codes (continued)
INITIATED CORRECTED ENTRY TIME
CODE DESCRIPTION NOTES EXAMPLES
BY DATA TYPE FRAME

CHANGE CODES FOR REFUSED NOTIFICATION OF CHANGE ENTRIES

Change codes C61-C69 are only to be used when refusing a Notification of Change. The refused Notification of Change process can only be used with Reason Codes C61 - C69. If a reason other than those listed (C61 - C69)
exists, the Entry should be handled outside of the refused Notification of Change process. (This limitation applies only to the refused Notification of Change process.)

C61 Misrouted Notification ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
of Change NOC NOC or corrected NOC each field of the Company/Batch Header

2 0 1 3 O P E R AT I N G R U L E S
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C62 Incorrect Trace Number ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
NOC NOC or corrected NOC each field of the Company/Batch Header
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C63 Incorrect Company ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Identification Number NOC NOC or corrected NOC each field of the Company/Batch Header
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C64 Incorrect Individual ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Identification Number/ NOC NOC or corrected NOC each field of the Company/Batch Header
Identification Number (COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C65 Incorrectly Formatted ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Corrected Data NOC NOC or corrected NOC each field of the Company/Batch Header
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C66 Incorrect Discretionary ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Data NOC NOC or corrected NOC each field of the Company/Batch Header
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.

OR171
APPENDIX FIVE – Notification of Change
 PART 5.3  Table of Change Codes (continued)
INITIATED CORRECTED ENTRY TIME

OR172
CODE DESCRIPTION NOTES EXAMPLES
BY DATA TYPE FRAME
C67 Routing Number Not ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
From Original Entry NOC NOC or corrected NOC each field of the Company/Batch Header
Detail Record (COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C68 DFI Account Number ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Not From Original Entry NOC NOC or corrected NOC each field of the Company/Batch Header
Detail Record (COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
otherwise noted in Appendix Five, part 5.4.
C69 Incorrect Transaction ODFI Refused 15 days from receipt of For refused Notification of Change Entries,
Code NOC NOC or corrected NOC each field of the Company/Batch Header
(COR) Record and the Entry Detail Record remain
unchanged from the NOC Entry, unless
APPENDIX FIVE – Notification of Change

otherwise noted in Appendix Five, part 5.4.

2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX FIVE – Notification of Change

PART 5.4  Record Formats for

Notifications of Change
The field contents for Notification of Change
Entries must match the field contents of the
original Entries unless otherwise noted in the
following Record formats. (See Appendix Three
(ACH Record Format Specifications) for the File
Header, Company/Batch Control, and File Control
Record formats.)

2 0 1 3 O P E R AT I N G R U L E S OR173
 SUBPART 5.4.1  Company/Batch Header Record Format for Notification of Change

OR174
NOTIFICATION OF CHANGE — COMPANY/BATCH HEADER RECORD
(excludes IAT Entries)

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

STANDARD
DATA RECORD SERVICE COMPANY ENTRY COMPANY COMPANY ORIGINATING
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY CLASS ENTRY DESCRIPTIVE EFFECTIVE SETTLEMENT ORIGINATOR DFI BATCH
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE ENTRY DATE DATE (JULIAN) STATUS CODE IDENTIFICATION NUMBER

Field
Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric1 Alphameric2 Alphameric YYMMDD Numeric Alphameric3 TTTTAAAA4 Numeric5

Length 1 3 16 20 10 3 10 6 6 3 1 8 7
APPENDIX FIVE – Notification of Change

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Notification of Change Entries, each field of the Company/Batch Header Record remains unchanged from the original entry, unless otherwise noted.
1  Contains ‘COR’ for all Notification of Change Entries.
2  May contain the identification of the ACH Operator converting the entry.
3  Changed to reflect the Originator Status Code of the institution initiating the Notification of Change Entry (i.e., the RDFI of the original entry).
4  Changed to reflect the Routing Number of the institution initiating the Notification of Change Entry.
5  Changed to the batch number assigned by the institution preparing the Automated Notification of Change Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 5.4.2  Company/Batch Header Record Formats for International ACH Transaction (IAT) Notification of Change

IAT COMPANY/BATCH HEADER RECORD FOR NOTIFICATIONS OF CHANGE

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
GO
FOREIGN ISO STANDARD ISO ISO IDENTIFICATION/
DATA RECORD SERVICE FOREIGN EXCHANGE FOREIGN DESTINATION ENTRY COMPANY ORIGINATING DESTINATION EFFECTIVE SETTLEMENT ORIGINATOR ORIGINATING
ELEMENT TYPE CLASS IAT EXCHANGE REFERENCE EXCHANGE COUNTRY ORIGINATOR CLASS ENTRY CURRENCY CURRENCY ENTRY DATE STATUS DFI BATCH
NAME CODE CODE INDICATOR INDICATOR INDICATOR REFERENCE CODE IDENTIFICATION CODE DESCRIPTION CODE CODE DATE (JULIAN) CODE IDENTIFICATION NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inserted by
Inclusion M M M M R R M M M M M M R M M M
ACH Operator
Requirement
1 2 3 4 5
Contents ‘5’ Numeric Alphameric Alphameric Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric TTTTAAAA Numeric

Length 1 3 16 2 1 15 2 10 3 10 3 3 6 3 1 8 7

Position 01-01 02-04 05-20 21-22 23-23 24-38 39-40 41-50 51-53 54-63 64-66 67-69 70-75 76-78 79-79 80-87 88-94

NOTE: For IAT Notification of Change Entries, each field of the Company/Batch Header Record remains unchanged from the original entry, unless otherwise noted.
1  This field must contain ‘IATCOR’ for all Notification of Change Entries related to IAT entries.
2  Contains ‘COR’ for all Notification of Change Entries
3  Changed to reflect the Originator Status Code of the institution initiating the Notification of Change Entry (i.e., the RDFI of the original entry).
4  Changed to reflect the Routing Number of the institution initiating the Notification of Change Entry (i.e., the RDFI of the original entry).
5  Changed to the batch number assigned by the institution preparing the Automated Notification of Change Entry.

OR175
APPENDIX FIVE – Notification of Change
 SUBPART 5.4.3  Corporate Entry Detail Record Format for Notification of Change

OR176
NOTIFICATION OF CHANGE — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M O R R N/A O M M

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Alphameric 00000000004 Alphameric Numeric Alphameric Blank Alphameric ‘1’ Numeric5

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94
APPENDIX FIVE – Notification of Change

NOTE: For Notification of Change Entries, each field of the Corporate Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the institution receiving the Notification of Change Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  This field must be zero filled.
5  Changed to the Trace Number assigned by the institution preparing the Automated Notification of Change Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 5.4.4  Entry Detail Record Format for Notification of Change
(excludes IAT Entries)

NOTIFICATION OF CHANGE — ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

INDIVIDUAL
INDIVIDUAL NAME/
DATA RECORD DFI IDENTIFICATION RECEIVING ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT NUMBER/ COMPANY DISCRETIONARY RECORD TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE DENTIFICATION DIGIT NUMBER AMOUNT IDENTIFICATION NUMBER NAME DATA INDICATOR NUMBER

Field
Inclusion M M M M R M O R O M M
Requirement

Contents ‘6’ Numeric1 TTTTAAAA 2 Numeric3 Alphameric 00000000004 Alphameric5 Alphameric5 Alphameric ‘1’ Numeric6

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

NOTE: For Notification of Change Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1 Changed to the appropriate Notification of Change Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2 Changed to the Routing Number of the institution receiving the Notification of Change Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  This field must be zero filled.
5 For CIE and MTE entries, positions 40-54 are used for a 15 character Individual Name, and positions 55-76 are used for a 22 character Individual Identification Number.
6  Changed to the Trace Number assigned by the institution preparing the Automated Notification of Change Entry.

OR177
APPENDIX FIVE – Notification of Change
 SUBPART 5.4.5  Addenda Record Format for Notification of Change

OR178
NOTIFICATION OF CHANGE ­— ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9

DATA ORIGINAL
ELEMENT RECORD ADDENDA CHANGE ORIGINAL ENTRY RECEIVING DFI CORRECTED TRACE
NAME TYPE CODE TYPE CODE CODE TRACE NUMBER RESERVED IDENTIFICATION DATA RESERVED NUMBER

Field
Inclusion
Requirement M M M M N/A R M N/A M

Contents ‘7’ ‘98’ Alphameric Numeric1 Blank TTTTAAAA2 Alphameric Blank Numeric

Length 1 2 3 15 6 8 29 15 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-64 65-79 80-94
APPENDIX FIVE – Notification of Change

1  Copy data from positions 80-94 of the original Entry Detail Record or Corporate Entry Detail Record.
2  Copy data from positions 04-11 of the original Entry Detail Record (the RDFI’s Routing Number).

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 5.4.6  Sequence of Records for Notification of Change for IAT Entries

IAT NOTIFICATION OF CHANGE — ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

GO NUMBER FOREIGN RECEIVER’S GATEWAY SECONDARY

DATA RECORD IDENTIFICATION/ OF ACCOUNT NUMBER/ OPERATOR OFAC OFAC ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ADDENDA DFI ACCOUNT SCREENING SCREENING RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT RECORDS RESERVED AMOUNT NUMBER RESERVED INDICATOR INDICATOR INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion M M M M M N/A M M N/A O O M M
Requirement

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Numeric Blank 00000000004 Alphameric Blank Alphameric Alphameric Numeric Numeric5

Length 1 2 8 1 4 13 10 35 2 1 1 1 15

Position 01-01 02-03 04-11 12-12 13-16 17-29 30-39 40-74 75-76 77-77 78-78 79-79 80-94

NOTE: For IAT Notification of Change Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1 Changed to the appropriate Notification of Change Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the institution receiving the Notification of Change Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  This field must be zero filled.
5  Changed to the Trace Number assigned by the institution preparing the Automated Notification of Change Entry.

OR179
APPENDIX FIVE – Notification of Change
 SUBPART 5.4.7  Addenda Record Format for IAT NOCs

OR180
IAT ADDENDA RECORD FOR NOC ENTRIES

FIELD 1 2 3 4 5 6 7 8 9

DATA ORIGINAL
ELEMENT RECORD TYPE ADDENDA TYPE CHANGE ORIGINAL ENTRY RECEIVING CORRECTED TRACE
NAME CODE CODE CODE TRACE NUMBER RESERVED DFI IDENTIFICATION DATA RESERVED NUMBER

Field
Inclusion M M M M N/A R M N/A M
Requirement

Contents ‘7’ ‘98’ Alphameric Numeric1 Blank TTTTAAAA2 Alphameric Blank Numeric

Length 1 2 3 15 6 8 35 9 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-70 71-79 80-94
APPENDIX FIVE – Notification of Change

1  Copy data from positions 80-94 of the IAT Entry Detail Record.
2  Copy data from positions 04-11 of the original Entry Detail Record (the RDFI’s Routing Number)

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 5.4.8  Company/Batch Header Record Format for Notification of Change
(excludes IAT Entries)

REFUSED NOTIFICATION OF CHANGE — COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

STANDARD
DATA RECORD SERVICE COMPANY ENTRY COMPANY COMPANY EFFECTIVE SETTLEMENT ORIGINATING
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY CLASS ENTRY DESCRIPTIVE ENTRY DATE ORIGINATOR DFI BATCH

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) STATUS CODE IDENTIFICATION NUMBER

Field
Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric1 TTTTAAAA2 Numeric3

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Refused NOC Entries, each field of the Company/Batch Header Record remains unchanged from the NOC entry, unless otherwise noted.
1  Changed to reflect the Originator Status Code of the institution initiating the Refused NOC Entry (i.e., the RDFI of the NOC Entry).
2  Changed to reflect the Routing Number of the institution initiating the Refused NOC Entry (i.e., the RDFI of the NOC Entry).
3  Changed to the Batch Number assigned by the institution preparing the Refused NOC Entry.

OR181
APPENDIX FIVE – Notification of Change
 SUBPART 5.4.9  Corporate Entry Detail Record Format for Refused Notification of Change

OR182
REFUSED NOTIFICATION OF CHANGE — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

RECEIVING
DATA RECORD DFI NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL IDENTIFICATION ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field Inclusion
Requirement M M M M R M O R R N/A R M M

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Numeric Alphameric Blank Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94
APPENDIX FIVE – Notification of Change

NOTE: For Refused NOC Entries, each field of the Corporate Entry Detail Record remains unchanged from the NOC entry, unless otherwise noted.
1  Changed to the Routing Number of the institution receiving the Refused NOC Entry (i.e., the ODFI of the NOC Entry).
2  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Refused NOC Entry (i.e., the RDFI of the NOC entry).

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 5.4.10  Entry Detail Record Format for Refused Notification of Change
(excludes IAT Entries)

REFUSED NOTIFICATION OF CHANGE — ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

INDIVIDUAL INDIVIDUAL
IDENTIFICATION NAME/
DATA RECORD DFI NUMBER/ RECEIVING ADDENDA

2 0 1 3 O P E R AT I N G R U L E S
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT IDENTIFICATION COMPANY DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME DATA INDICATOR NUMBER

Field
Inclusion M M M M R M O R R M M
Requirement

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Alphameric Alphameric Alphameric ‘1’ Numeric3

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

NOTE: For Refused NOC Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1 Changed to the Routing Number of the institution receiving the Refused NOC Entry (i.e., the ODFI of the NOC Entry).
2  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
3  Changed to the Trace Number assigned by the institution preparing the Refused NOC Entry (i.e., the RDFI of the NOC Entry).

OR183
APPENDIX FIVE – Notification of Change
 SUBPART 5.4.11  Addenda Record Format for Refused Notification of Change
(excludes IAT Entries)

OR184
REFUSED NOTIFICATION OF CHANGE — ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD ADDENDA ORIGINAL COR TRACE

ELEMENT TYPE TYPE REFUSED COR ORIGINAL ENTRY RECEIVING DFI CORRECTED SEQUENCE TRACE
NAME CODE CODE CODE TRACE NUMBER RESERVED IDENTIFICATION DATA CHANGE CODE NUMBER RESERVED NUMBER

Field
Inclusion
Requirement M M M M N/A R M M M N/A M

Contents ‘7’ ‘98’ Alphameric Numeric1 Blank TTTTAAAA Alphameric Alphameric2 Numeric Blank Numeric

Length 1 2 3 15 6 8 29 3 7 5 15

Position 01-01 02-03 04-06 07-21 22-27 28-35 36-64 65-67 68-74 75-79 80-94
APPENDIX FIVE – Notification of Change

NOTE: This record format should only be used in the refusal of a Notification of Change Entry.
1  Copy data from positions 07-21 of the Addenda Record of the original Notification of Change.
2  Copy data from positions 04-06 of the Addenda Record of the original Notification of Change.

2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX SIX – Acknowledgment Entries

PART 6.2  Refused Acknowledgment

Entries
APPENDIX SIX
A Refused Acknowledgment Entry is created by
Acknowledgment an ODFI to refuse an Acknowledgment Entry that
is misrouted or contains incorrect or incomplete
Entries information. Each Refused Acknowledgment
Entry Transmitted by an ODFI must be in the
format and sequence defined in this Appendix Six
An Acknowledgment Entry is created by an RDFI and must contain the reason(s) for the refusal of
to provide notice to the ODFI that a corporate the Acknowledgment Entry.
credit entry initiated using a CCD or CTX format
has been received by the RDFI. PART 6.3   Table of Codes for Refused
Acknowledgment Entries
PART 6.1  Acknowledgment Entries
Table of Codes for Refused
An Acknowledgment Entry must comply with the Acknowledgment Entries
following specifications:
CODE MEANING
• The Company/Batch Header Record, Entry Codes A1 - A3 are only to be used when
Detail Record, and Addenda Record formats refusing an Acknowledgment Entry.

defined in this Appendix Six must be used. A1 Misrouted Acknowledgment Entry

• The Standard Entry Class Code “ACK” or A2 Incorrect Trace Number

“ATX” must be used to denote a batch
containing Acknowledgment Entries. Incorrect Company Identification
A3
Number

• The Transaction Code must be either “24” or

“34”. PART 6.4  Record Formats for
Acknowledgment and Refused
• The amount field must be zero. Acknowledgment Entries
Unless otherwise noted in the following Record
• An Acknowledgement Entry may contain
formats, the field contents for an Acknowledgment
one optional Addenda Record. Addenda
Entry and a Refused Acknowledgment Entry
Type Code “05” is used to indicate that the
match the field contents of the original CCD or
Addenda Record contains acknowledgment
CTX Entry to which the Acknowledgement Entry
information.
relates. (See Appendix Three, ACH Record Format
Specifications, for the File Header, Company/Batch
• For an ACK+ or ATX+, Field 3 of the Addenda
Control, and File Control Record formats.)
Record contains an ANSI ASC X12 REF
(Reference) Data Segment to acknowledge
the RDFI’s receipt of a financial EDI credit
payment as agreed by the trading partners.

2 0 1 3 O P E R AT I N G R U L E S OR185
 SUBPART 6.4.1  Company/Batch Header Record Format for Acknowledgment Entries (ACK and ATX)

OR186
ACKNOWLEDGMENT ENTRIES — COMPANY/BATCH HEADER RECORD FORMAT (ACK and ATX)

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

STANDARD
DATA RECORD SERVICE COMPANY ENTRY COMPANY COMPANY SETTLEMENT
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY CLASS ENTRY DESCRIPTIVE EFFECTIVE DATE ORIGINATOR ORIGINATING DFI BATCH
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE ENTRY DATE (JULIAN) STATUS CODE IDENTIFICATION NUMBER

Field Inclusion Inserted by

Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric1 Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric2 TTTTAAAA3 Numeric4

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94
APPENDIX SIX – Acknowledgment Entries

NOTE: For Acknowledgment Entries, each field of the Company/Batch Header Record remains unchanged from the original entry, unless otherwise noted.
1  Contains ‘200’ for Acknowledgment Entries.
2  Changed to reflect the Originator Status Code of the institution initiating the Acknowledgment Entry (i.e., the RDFI of the original entry).
3  Changed to reflect the Routing Number of the Institution initiating the Acknowledgment Entry (i.e., the RDFI of the original entry).
4  Changed to the batch number assigned by the institution preparing the Acknowledgment Entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 6.4.2  Entry Detail Record Format for ACK Entries

ACK ENTRIES — ENTRY DETAIL RECORD FORMAT

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD ADDENDA

ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT ORIGINAL ENTRY RECEIVING DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT TRACE NUMBER COMPANY NAME DATA INDICATOR NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion
Requirement M M M M R M M R O M M

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Alphameric $$$$$$$$¢¢ Numeric4 Alphameric Alphameric Numeric Numeric5

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94

ACK ENTRIES — ADDENDA RECORD FORMAT

FIELD 1 2 3 4 5

DATA
ELEMENT RECORD TYPE ADDENDA TYPE PAYMENT RELATED ADDENDA ENTRY DETAIL
NAME CODE CODE INFORMATION SEQUENCE NUMBER SEQUENCE NUMBER

Field
Inclusion
Requirement M M O M M

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

NOTE: For ACK Entries, each field of the Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate ACK Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the Institution receiving the ACK Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  Copy data from positions 80-94 of the original Entry Detail Record.
5  Changed to the Trace Number assigned by the institution preparing the ACK entry.

OR187
APPENDIX SIX – Acknowledgment Entries
 SUBPART 6.4.3  Corporate Entry Detail Record Format for ATX Entries

OR188
ATX ENTRIES — CORPORATE ENTRY DETAIL RECORD FORMAT

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

ORIGINAL RECEIVING
DATA RECORD DFI ENTRY NUMBER OF COMPANY ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL TRACE ADDENDA NAME/ID DISCRETIONARY RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS NUMBER RESERVED DATA INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M M M R N/A O M M

Contents ‘6’ Numeric1 TTTTAAAA2 Numeric3 Alphameric $$$$$$$$¢¢ Numeric4 Numeric Alphameric Blank Alphameric Numeric Numeric5

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94
APPENDIX SIX – Acknowledgment Entries

ATX ENTRIES — ADDENDA RECORD FORMAT

FIELD 1 2 3 4 5

DATA RECORD TYPE ADDENDA TYPE PAYMENT RELATED INFORMATION ADDENDA ENTRY DETAIL
ELEMENT CODE CODE SEQUENCE NUMBER SEQUENCE NUMBER
NAME

Field M M O M M
Inclusion
Requirement

Contents ‘7’ ‘05’ Alphameric Numeric Numeric

Length 1 2 80 4 7

Position 01-01 02-03 04-83 84-87 88-94

NOTE: For ATX Entries, each field of the Corporate Entry Detail Record remains unchanged from the original entry, unless otherwise noted.
1  Changed to the appropriate ATX Entry Transaction Code. (See Transaction Codes under currently assigned “Code Values” in Appendix Three.)
2  Changed to the Routing Number of the institution receiving the ATX Entry (i.e., the ODFI of the original entry).
3  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
4  Copy data from positions 80-94 of the original Corporate Entry Detail Record.
5  Changed to the Trace Number assigned by the institution preparing the ATX entry.

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 6.4.4  Company/Batch Header Record Format for Refused Acknowledgment Entries

REFUSED ACKNOWLEDGMENT ENTRIES — COMPANY/BATCH HEADER RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD SERVICE COMPANY STANDARD COMPANY COMPANY EFFECTIVE SETTLEMENT ORIGINATOR
ELEMENT TYPE CLASS COMPANY DISCRETIONARY COMPANY ENTRY CLASS ENTRY DESCRIPTIVE ENTRY DATE STATUS ORIGINATING DFI BATCH
NAME CODE CODE NAME DATA IDENTIFICATION CODE DESCRIPTION DATE DATE (JULIAN) CODE IDENTIFICATION NUMBER

2 0 1 3 O P E R AT I N G R U L E S
Field
Inclusion Inserted by
Requirement M M M O M M M O R ACH Operator M M M

Contents ‘5’ Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric1 TTTTAAAA2 Numeric3

Length 1 3 16 20 10 3 10 6 6 3 1 8 7

Position 01-01 02-04 05-20 21-40 41-50 51-53 54-63 64-69 70-75 76-78 79-79 80-87 88-94

NOTE: For Refused Acknowledgment Entries, each field of the Company/Batch Header Record remains unchanged from the Acknowledgment entry, unless otherwise noted.
1  Changed to reflect the Originator Status Code of the institution initiating the Refused Acknowledgment Entry (i.e., the RDFI of the Acknowledgment Entry).
2  Changed to reflect the Routing Number of the institution initiating the Refused Acknowledgment Entry (i.e., the RDFI of the Acknowledgment Entry).
3  Changed to the Batch Number assigned by the institution preparing the Refused Acknowledgment Entry.

OR189
APPENDIX SIX – Acknowledgment Entries
 SUBPART 6.4.5  Entry Detail Record Format for Refused ACK Entries

OR190
REFUSED ACK ENTRIES — ENTRY DETAIL RECORD FORMAT

FIELD 1 2 3 4 5 6 7 8 9 10 11

ORIGINAL
DATA RECORD ENTRY RECEIVING REFUSED ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK DFI ACCOUNT TRACE COMPANY ACKNOWLEDGMENT RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER NAME CODE INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M M R M M M

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Numeric3 Alphameric Alphameric Numeric Numeric4

Length 1 2 8 1 17 10 15 22 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-76 77-78 79-79 80-94
APPENDIX SIX – Acknowledgment Entries

NOTE: For Refused ACK Entries, each field of the Entry Detail Record remains unchanged from the ACK entry, unless otherwise noted.
1  Changed to the Routing Number of the institution receiving the Refused ACK Entry (i.e., the ODFI of the ACK Entry).
2  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
3  Copy data from positions 40-54 of the ACK entry.
4  Changed to the Trace Number assigned by the institution preparing the Refused ACK Entry (i.e., the RDFI of the ACK Entry).

2 0 1 3 O P E R AT I N G R U L E S
 SUBPART 6.4.6  Corporate Entry Detail Record Format for Refused ATX Entries

REFUSED ATX ENTRIES — CORPORATE ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

ORIGINAL RECEIVING
DATA RECORD DFI ENTRY NUMBER OF COMPANY REFUSED ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ACCOUNT TOTAL TRACE ADDENDA NAME/ ACKNOWLEDGMENT RECORD TRACE

2 0 1 3 O P E R AT I N G R U L E S
NAME CODE CODE IDENTIFICATION DIGIT NUMBER AMOUNT NUMBER RECORDS ID NUMBER RESERVED CODE INDICATOR NUMBER

Field
Inclusion
Requirement M M M M R M M M R N/A M M M

Contents ‘6’ Numeric TTTTAAAA1 Numeric2 Alphameric $$$$$$$$¢¢ Numeric3 Numeric Alphameric Blank Alphameric Numeric Numeric4

Length 1 2 8 1 17 10 15 4 16 2 2 1 15

Position 01-01 02-03 04-11 12-12 13-29 30-39 40-54 55-58 59-74 75-76 77-78 79-79 80-94

NOTE: For Refused ATX Entries, each field of the Corporate Entry Detail Record remains unchanged from the ATX entry, unless otherwise noted.
1  Changed to the Routing Number of the institution receiving the Refused ATX Entry (i.e., the ODFI of the ATX Entry).
2  Changed to the Check Digit calculated according to NACHA standards and based on the Routing Number contained in positions 04-11.
3  Copy data from positions 40-54 of ATX entry.
4  Changed to the Trace Number assigned by the institution preparing the Refused ATX Entry (i.e., the RDFI of the ATX entry).

OR191
APPENDIX SIX – Acknowledgment Entries
APPENDIX SEVEN – Compensation Rules

PART 7.4  Beneficiaries

APPENDIX SEVEN Only Participating DFIs have any rights under
these rules. These rules do not give any rights to
Compensation Rules any other person.

PART 7.5  Definitions

PART 7.1  Scope
SUBPART 7.5.1  “Federal Funds Rate”
The rules in this Appendix Seven govern the
means the average of each day’s Federal Funds
settlement of claims for compensation between
Rate for the days that a Participating DFI is, under
Participating DFIs. These rules apply regardless
these rules, to include in the applicable formula
of the original source or ultimate beneficiary of
used to calculate compensation. The Federal Funds
any Entry, the manner in which the Entry was
Rate is that rate published on a daily basis by the
Transmitted, or the nature of the transaction to
Federal Reserve Bank of New York. For any day on
which the Entry relates. A compensation claim
which a published rate is not available, the Federal
shall be paid for an Entry only if the loss suffered
Funds Rate is considered to be the same as the
by the claimant is at least $200 per that Entry. The
immediately preceding published rate.
amount of loss suffered by a claimant shall be
calculated using the applicable formula provided in
SUBPART 7.5.2  “Deposit Insurance Assessment”
this Appendix Seven, excluding the administrative
fee of $200 per Entry added to or subtracted from means either:
such formula and adding any applicable Deposit
Insurance Assessment as described in Subpart (1) the amount of the increase, if any, in an
7.5.2 (Deposit Insurance Assessment) of this FDIC assessment paid or payable by the
Appendix Seven. RDFI because the relevant Entry increased
the base upon which the FDIC assessment
is calculated. The amount of the increase
PART 7.2  Nature of the Rules
will be calculated using the assessment rate
Not every possible scenario concerning a adopted by the FDIC for the lowest risk
compensation claim is explicitly addressed in classification in its risk-related schedule.
this Appendix Seven. When a valid claim for
compensation is not covered by these rules, or
Participating DFIs are expected to settle the claim
so that no Participating DFI is unjustly enriched or (2) 
in the case of credit unions, the amount
injured. In general, compensation related to a claim of the increase, if any, in (a) the amount
must not exceed the benefit that was received by the of deposits required to be maintained
Participating DFI obligated to pay compensation. by the RDFI with the NCUSIF (equaling
However, compensation may include interest and one percent of the total of the credit
penalties incurred by a Participating DFI as a union’s insured shares as of the close of
result of an overdraft. Payment or a request for the preceding insurance year) because
payment of compensation under these rules does the relevant Entry increased the base
not constitute and shall not be construed as an upon which the deposits required to be
admission of negligence or fault on the part of any maintained will be calculated, and (b) the
Participating DFI involved. increase, if any, in the deposit insurance
premium paid or payable by the RDFI
PART 7.3  Manner of Payment to the NCUSIF for that insurance year
A compensation payment may be made by an (equaling one-twelfth of one percent of
Entry or by check. Participating DFIs may alter the credit union’s total insured shares as of
the manner of payment of compensation by prior the close of the preceding insurance year)
mutual agreement. because the relevant Entry increased the
base upon which the insurance premium
will be calculated.

OR192 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX SEVEN – Compensation Rules

SUBPART 7.5.3 Compensation =

Unless otherwise defined, the terms used in this (Dollar Amount of Payment)
Appendix Seven shall have the meaning ascribed (100% - Reserve Requirement)
+   ($200 + Applicable Deposit
to them in Article Eight (Definitions of Terms Used (Federal Funds Rate)
Insurance Assessment)
(No. of Days Forward Valued)
in These Rules). 360

PART 7.6  Back Valuation An RDFI claiming an applicable Deposit Insurance

Assessment warrants to the ODFI that such amount
SUBPART 7.6.1  Credit Entries
has not been and will not be recovered. If an
(1) 
An ODFI which Transmitted a credit
RDFI adjusts the Entry in response to the ODFI’s
Entry may request the RDFI to back
request, the RDFI is entitled to compensation
value the Entry. Generally, such request is
for the applicable Deposit Insurance Assessment
accompanied by a payment for the amount
even if the ODFI does not claim compensation.
of compensation owed according to the
However, the RDFI’s claim for compensation must
formula in (2) below. If compensation
be made within 90 days from the date on which
is paid, the RDFI shall back value the
the requested adjustment was made.
payment to the date requested, unless one
or more of the following conditions exists: If a claim for compensation has been made by
(a) the Receiver instructs it not to back the ODFI and the compensation is calculated to
value such Entry; (b) the Receiver’s account be zero or a negative number, neither the RDFI
has been closed; or (c) the ODFI requests nor the ODFI shall pay any compensation unless
a back valuation to a date more than one a claim for an applicable Deposit Insurance
year prior to the effective entry date of Assessment has been made. However, if a claim for
the Entry. If compensation is paid, and the an applicable Deposit Insurance Assessment has
RDFI does not back value such Entry, the been made and the compensation is calculated to
compensation amount shall be promptly be a negative number, the ODFI shall pay the RDFI
repaid by the RDFI to the ODFI. the amount of the compensation calculated, i.e., the
absolute value of the negative number calculated,
(2) If the RDFI back values the Entry in response
provided such value is $1000 or greater. If a claim
to the request of the ODFI, the ODFI shall
for compensation has not been made by the ODFI
pay the RDFI compensation according to
and the RDFI has made a claim for an applicable
the following formula (without regard to
Deposit Insurance Assessment, the ODFI shall pay
whether or not the Receiver’s account was
compensation, provided the value of such claim is
actually in an overdraft position):
$1000 or greater.

Compensation =
PART 7.8  Return or Reversal of
(Dollar Amount of Entry) Erroneous Entry
(Federal Funds Rate)
+  $200
(No. of Days Forward Valued)
360 SUBPART 7.8.1  Credit Entries
(1) If an ODFI has Transmitted an erroneous
credit Entry and the RDFI returns the Entry
PART 7.7  Forward Valuation
according to Article Two, Subsection 2.12.2
Credit Entries – (1) An ODFI which Transmitted (ODFI Request for Return), or if the Entry is
a credit Entry may request the RDFI to adjust the reversed according to Article Two, Section
payment to a future value date. The RDFI is not 2.9 (Reversing Entries), the RDFI must pay
obligated to make such an adjustment. (2) If the the ODFI compensation according to the
RDFI makes the requested adjustment, the RDFI following formula, upon receipt of a claim
shall, upon receiving a claim for compensation for compensation within 90 days of the
within 90 days from the date on which such Settlement Date of the Return or Reversal.
adjustment was made, pay the ODFI compensation
according to the following formula:

2 0 1 3 O P E R AT I N G R U L E S OR193
APPENDIX SEVEN – Compensation Rules

Compensation = Compensation =

(Dollar Amount of Erroneous Entry) (Dollar Amount of Erroneous Entry)

(100% - Reserve Requirement) (Federal Funds Rate)
(Federal Funds Rate) (No. of Days From Settlement +  ($200 + Applicable
(No. of Days From Settlement Date +   ($200 + Applicable Deposit Date of Erroneous Entry to DepositInsurance
of Erroneous Entry to Insurance Assessment) Settlement Date of Return or Assessment)
Settlement Date of Return or Reversal – Not to Exceed 180)
Reversal – Not to Exceed 180) 360
360

If a missent debit Entry is retained by the RDFI for

An RDFI claiming an applicable Deposit Insurance more than 180 days, the Federal Funds Rate means
Assessment warrants to the ODFI that such amount the Federal Funds Rate in effect during the most
has not been and will not be recovered. If an recent 180 day time period.
RDFI adjusts the Entry in response to the ODFI’s
request, the RDFI is entitled to compensation
PART 7.9  Change of Beneficiary
for the applicable Deposit Insurance Assessment
even if the ODFI does not claim compensation. SUBPART 7.9.1  Credit Entries
However, the RDFI’s claim for compensation must
If an ODFI has Transmitted a credit Entry to the
be made within 90 days from the date on which
correct RDFI but the Entry was to the wrong
the requested adjustment was made.
account or omitted account information, and
the RDFI adjusts the Entry at the request of the
If a claim for compensation has been made by
ODFI, the ODFI must pay the RDFI compensation
the ODFI and the compensation is calculated to
according to the following formula, provided that a
be zero or a negative number, neither the RDFI
request for back valuation is made within 180 days
nor the ODFI shall pay any compensation unless
of the effective entry date of the Entry. This part
a claim for an applicable Deposit Insurance
applies whether or not the beneficiary’s account
Assessment has been made. However, if a claim for
was actually in an overdraft position.
an applicable Deposit Insurance Assessment has
been made and the compensation is calculated to
Compensation =
be a negative number, the ODFI shall pay the RDFI
(Dollar Amount of Entry)
the amount of the compensation calculated, i.e., the (Reserve Requirement)
absolute value of the negative number calculated, (Federal Funds Rate)
+  $200
(No. of Days From Receipt to
provided such value is $1000 or greater. If a claim Adjustment – Not to exceed 180)
for compensation has not been made by the ODFI 360
and the RDFI has made a claim for an applicable
Deposit Insurance Assessment, the ODFI shall pay NOTE: For purposes of this rule, “No. of Days”
compensation, provided the value of such claim is means a period no longer than two business
$1000 or greater. days beyond the date on which an Indemnity is
received.
(2) If a missent credit Entry is retained by the
RDFI for more than 180 days, the Federal
SUBPART 7.9.2  Debit Entries
Funds Rate means the Federal Funds Rate
in effect during the most recent 180 day If an ODFI has Transmitted a debit Entry to the
time period. correct RDFI but the Entry was to the wrong
account or omitted account information, and
the RDFI adjusts the Entry at the request of the
SUBPART 7.8.2  Debit Entries
ODFI, the ODFI must pay the RDFI compensation
If an ODFI has Transmitted an erroneous debit
according to the following formula, provided that
Entry and the RDFI returns the Entry according
a request for back valuation is made within 180
to Article Two, subsection 2.12.2 (ODFI Request
days from the effective entry date of the Entry.
for Return), the ODFI must pay the RDFI
compensation upon its request according to the
following formula:

OR194 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX EIGHT – Rule Compliance Audit Requirements

Compensation = A Participating DFI may wish to audit other

(Dollar Amount of Entry)
aspects of its ACH operations in conjunction with
(Reserve Requirement) its annual rules compliance audit. These aspects
(Federal Funds Rate) could include OFAC compliance, ACH business
+  $200
(No. of Days From Receipt to
Adjustment – Not to exceed 180) continuity plans, ACH risk management policies,
360 and compliance with 31 C.F.R. Part 210 and the
Green Book for processing Federal Government
NOTE: For purposes of this rule, “No. of Days” ACH transactions.
means a period no longer than two business days
beyond the date on which an indemnity is received. PART 8.1  General Audit Requirements
Each Participating DFI, Third-Party Service Provider,
and Third-Party Sender must, in accordance with
APPENDIX EIGHT standard auditing procedures, conduct an internal
or external audit of compliance with provisions of
Rule Compliance the ACH rules in accordance with the requirements
of this Appendix Eight. These audit provisions do
Audit Requirements not prescribe a specific methodology to be used
for the completion of an audit but identify key rule
provisions that should be examined during the
Participating DFIs, Third-Party Service Providers, audit process. An annual audit must be conducted
and Third-Party Senders must comply with all under these Rule Compliance Audit Requirements
provisions of these Rules and conduct an audit of no later than December 31 of each year. This audit
such compliance on an annual basis. This audit must be performed under the direction of the audit
obligation is not limited to compliance with any committee, audit manager, senior level officer, or
specific rule or group of rules, and the descriptions independent (external) examiner or auditor of the
of rules contained within this Appendix Eight are Participating DFI, Third-Party Service Provider,
not intended to modify or limit the language of the or Third-Party Sender. The Participating DFI,
Rules themselves or the obligation of Participating Third-Party Service Provider or Third-Party Sender
DFIs, Third-Party Service Providers or Third-Party must retain proof that it has completed an audit
Senders to comply with, or to audit compliance of compliance in accordance with these rules.
with, such rules. Documentation supporting the completion of an
audit must be (1) retained for a period of six years
This Appendix Eight provides Participating from the date of the audit, and (2) provided to
DFIs, Third-Party Service Providers, and Third- the National Association upon request. Failure of
Party Senders with highlights of the most critical a Participating DFI to provide proof of completion
components of an audit of compliance with these of an audit according to procedures determined
Rules. The requirements relate solely to compliance by the National Association may be considered a
with these rules and do not address other audit Class 2 rule violation pursuant to Appendix Ten,
considerations of a financial institution’s ACH subpart 10.4.7.4 (Class 2 Rules Violation).
policies, procedures or regulatory compliance.
For Third-Party Service Providers and Third Party PART 8.2  Audit Requirements for All
Senders, these audit requirements apply only to Participating DFIs
the ACH functions that they perform on behalf
Each Participating DFI, Third-Party Service
of a Participating DFI and the performance of
Provider, and Third-Party Sender must conduct
any obligations of an ODFI under these Rules.
the following audit of ACH operations. These audit
References in this Appendix Eight to audit of an
specifications apply generally to all Participating
ODFI or RDFI performance therefore also apply
DFIs, regardless of a Participating DFI’s status as
to Third-Party Service Providers and Third Party
an ODFI or RDFI.
Senders acting on behalf of a Participating DFI.

2 0 1 3 O P E R AT I N G R U L E S OR195
APPENDIX EIGHT – Rule Compliance Audit Requirements

a. 
Verify that a Record of each Entry is PART 8.3  Audit Requirements for RDFIs
retained for six years from the date the
In addition to the audit procedures outlined in
Entry was Transmitted, except as otherwise
Parts 8.1 (General Audit Requirements) and 8.2
expressly provided in these Rules. Verify
(Audit Requirements for All Participating DFIs)
that a printout or reproduction of the
of this Appendix Eight, all RDFIs and their Third-
information relating to the Entry can be
Party Service Providers must conduct an audit of
provided, if requested by the Participating
the following relating to the receipt of ACH entries:
DFI’s customer or any other Participating
DFI or ACH Operator that originated, a. Verify that the account number contained
Transmitted, or received the Entry. (Article in a Prenotification Entry is for a valid
One, subsections 1.4.1 and 1.4.2) account. If the Prenotification does not
contain a valid account number, or is
b. 
When a Record required by these Rules
otherwise erroneous or unprocessable,
is created or retained in an Electronic
verify that the RDFI Transmits either (a)
form, verify that the Electronic form (a)
a Return Entry, or (b) a Notification of
accurately reflects the information in
Change. (Article Three, section 3.5)
the Record, and (b) is capable of being
accurately reproduced for later reference, b. Verify that, if the RDFI chooses to initiate
whether by Transmission, printing, or Notifications of Change, such COR Entries
otherwise. (Article One, subsection 1.4.3) are Transmitted within two banking days of
the Settlement Date of the entry to which
c. Verify that the Participating DFI conducted
the Notification of Change relates, with the
an audit of its compliance with the rules
exception of Notifications of Change due to
in accordance with Appendix Eight (Rule
merger, acquisition, or other similar events.
Compliance Audit Requirements) for the
(Article Three, subsection 3.9.1)
previous year. (Article One, subsection
1.2.2) c. Verify that, subject to the RDFI’s right of
return, all types of Entries that comply with
d. Verify that required encryption or a secure
these Rules and are received with respect
session is used for banking information
to an account maintained with the RDFI
transmitted via an Unsecured Electronic
are accepted. Verify that the RDFI handles
Network. (Article One, subsection 1.6)
XCK entries and entries to non-transaction
accounts appropriately. (Article Three,
e. Verify that the Participating DFI has reported
subsections 3.1.1 and 3.8.2)
and paid to the National Association (a)
all annual fees, and (b) a per-Entry fee for
d. Verify that, subject to the RDFI’s right of
each Entry that is Transmitted or received
return, the amount of each credit Entry
by the Participating DFI, including those
received from its ACH Operator is made
Entries that are not processed through
available to the Receiver for withdrawal no
an ACH Operator but are exchanged with
later than the Settlement Date of the Entry.
another non-affiliated Participating DFI.
In the case of a credit PPD Entry that is
(Article One, subsection 1.10)
made available to the RDFI by its ACH
Operator by 5:00 p.m. (RDFI’s local time)
f. 
Verify that the Participating DFI has
on the Banking Day prior to the Settlement
conducted an assessment of the risks of its
Date, verify that the amount is made
ACH activities and has implemented a risk
available to the Receiver for withdrawal at
management program on the basis of such
the opening of business on the Settlement
an assessment. (Article One, subsection
Date. Verify that debit entries are not
1.2.4)

OR196 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX EIGHT – Rule Compliance Audit Requirements

posted prior to the Settlement Date, even if h. Verify that the RDFI returns any credit Entry
the Effective Date of the Entry is different that is refused by a Receiver by Transmitting
from the Settlement Date of the Entry. a Return Entry to its ACH Operator by the
(Article Three, subsections 3.3.1.1, 3.3.1.2, ACH Operator’s deposit deadline for the
and 3.3.2) Return Entry to be made available to the
ODFI no later than the opening of business
e. 
For Consumer Accounts, verify that the on the second Banking Day following the
RDFI provides or makes available to each RDFI’s receipt of notification from the
of its Receivers required information Receiver that it has refused the Entry.
concerning each credit and debit Entry Also verify that the RDFI returns all credit
to a Consumer Account of such Receiver. Entries that are not credited or otherwise
(Article Three, subsection 3.1.5.1) made available to its Receivers’ accounts
by Transmitting a Return Entry to its ACH
For non-Consumer Accounts, verify that the Operator by the ACH Operator’s deposit
RDFI provides or makes available to the deadline for the Return Entry to be made
Receiver the contents of the Check Serial available to the ODFI no later than the
Number Field of an ARC, BOC, or POP opening of business on the second Banking
Entry. (Article Three, subsection 3.1.5.2) Day following the Settlement Date of the
original Entry. (Article Three, subsections
f. For all entries except RCK: 3.8.3.2 and 3.8.4)

Verify that the RDFI Transmits Return i. Verify that the RDFI honors stop payment
Entries to its ACH Operator by the ACH orders provided by Receivers, either
Operator’s deposit deadline for the Return verbally or in writing, to the RDFI at least
Entries to be made available to the ODFI three Banking Days before the scheduled
no later than the opening of business on date of any debit Entry to a Consumer
the second Banking Day following the Account other than a Single Entry. Verify
Settlement Date of the original Entry, that the RDFI honors stop payment orders
except as otherwise provided in these provided by Receivers to the RDFI at such
rules. (Article Three, section 3.8) time and in such manner as to allow the
RDFI a reasonable opportunity to act

Verify that late returns of unauthorized
upon the order prior to acting on any
CCD or CTX Entries are Transmitted with
debit Entry to a non-Consumer Account,
the agreement of the ODFI and that such
or an ARC, BOC, POP, or RCK Entry, or a
entries utilize the appropriate Return
Single Entry IAT, PPD, TEL, or WEB Entry.
Reason Code. (Article Three, subsection
to a Consumer Account. (Article Three,
3.8.3.5; Appendix Four)
subsections 3.7.1.1, 3.7.1.2 and 3.7.2)

Verify that dishonored Return Entries
Verify that the RDFI uses Return Reason
received by the RDFI are handled
Codes R38 (Stop Payment on Source
appropriately, and that contested
Document) and R52 (Stop Payment on Item
dishonored Return Entries and corrected
Related to RCK Entry) properly. Verify that,
Return Entries are initiated in a timely
for each ARC, BOC, or RCK Entry for which
manner. (Article Three subsection 3.8.5;
a stop payment order was in force with
Appendix Four)
respect to (a) the Check that was used as
an Eligible Source Document for the ARC or
g. Verify that Return Entries relating to RCK
BOC Entry, or (b) the item to which the RCK
Entries are Transmitted to the RDFI’s ACH
Entry relates, the Extended Return Entry is
Operator by midnight of the RDFI’s second
Transmitted to the RDFI’s ACH Operator
Banking Day following the Banking Day of
by its deposit deadline for the Extended
the receipt of the RCK Entry. (Article Three,
Return Entry to be made available to the
subsection 3.8.3.3)
ODFI no later than the opening of business

2 0 1 3 O P E R AT I N G R U L E S OR197
APPENDIX EIGHT – Rule Compliance Audit Requirements

on the Banking Day following the sixtieth an audit of the following relating to the origination
calendar day following the Settlement of ACH entries:
Date of the original Entry. (NOTE: No
Written Statement of Unauthorized Debit a. 
Verify that the ODFI has entered into
is required for entries returned for these Origination Agreements with all Originators
reasons.) (Article Three, subsections or Third-Party Senders that bind the
3.11.2.2 and 3.13.1; Appendix Four) Originator or Third-Party Sender to these
Rules; that authorize the ODFI to originate
j. 
Verify that Written Statements of entries on behalf of the Originator or Third-
Unauthorized Debit are obtained from Party Sender; that, within such agreements,
consumers for all returns bearing Return the Originator or Third-Party Sender
Reason Codes R05, R07, R10, R37, R51, and acknowledges that Entries may not be
R53, and that each Extended Return Entry initiated that violate the laws of the United
is Transmitted to the RDFI’s ACH Operator States; that includes any restrictions on
by its deposit deadline for the Extended types of Entries that may be originated; that
Return Entry to be made available to the includes that the Third-Party has entered
ODFI no later than the opening of business into an agreement with each Originator/
on the Banking Day following the sixtieth and that such agreements include the right
calendar day following the Settlement Date of the ODFI to terminate or suspend the
of the original Entry. Verify that copies agreement for breach of the Rules, and the
of Written Statements of Unauthorized right of the ODFI to audit the Originator’s,
Debits are provided to the ODFI within the the Third-Party Sender’s and the Third-
required time frame, when such copies are Party Sender’s Originators’ compliance
requested in writing by the ODFI. (Article with the Origination Agreement and the
Three subsection 3.11.1, 3.12.4, 3.12.6; and Rules. With respect to IAT Entries, verify
3.13.1; Appendix Four) that agreements contain all necessary
provisions. (Article Two, subsections
k. 
Verify that the RDFI has provided the 2.2.1.1, 2.2.1.2 and 2.5.8.3)
Receiver with proper notice to ensure
compliance with UCC Article 4A with b. 
Verify that, if applicable, the ODFI has
respect to ACH credit transactions. (Article entered into agreements with all Sending
Three, subsection 3.1.6) Points that Transmit Entries on the ODFI’s
behalf to an ACH Operator. (Article Two,
l. 
Verify that, when requested to do so by subsection 2.2.1.3)
the non-Consumer Receiver, the RDFI
provides all information contained within c. 
Verify that the ODFI has assessed the
the payment-related information field of risks of the Originator’s or Third-Party
an Addenda Record(s) Transmitted with a Sender’s ACH activity, and has established,
CCD, CTX, CIE, or IAT Entry. The RDFI must implemented and periodically reviewed an
provide this information by the opening of exposure limit for each Originator or Third-
business on the RDFI’s second Banking Party Sender. Verify that the ODFI has
Day following the Settlement Date of the established and implemented procedures
Entry. (Article Three, subsection 3.1.5.3) to monitor the Originator’s or Third-Party
Sender’s origination and return activity
PART 8.4  Audit Requirements for ODFIs across multiple Settlement Dates; enforce
In addition to the audit procedures outlined in restrictions on the types of Entries that may
Parts 8.1 (General Audit Requirements) and 8.2 be originated; and enforce the exposure
(Audit Requirements for All Participating DFIs) of limit. (Article Two, subsection 2.2.2)
this Appendix Eight, ODFIs, Third-Party Service
d. Verify that the ODFI accepts Return Entries
Providers, and Third-Party Senders must conduct
and Extended Return Entries that comply
with these Rules and that are Transmitted by
the RDFI within the time limits established

OR198 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX EIGHT – Rule Compliance Audit Requirements

by these Rules. Verify that dishonored with an Originator directly, also verify
Return Entries are Transmitted within five that the Third-Party Sender has utilized
banking days after the Settlement Date a commercially reasonable method to
of the Return Entry and that contested establish the identity of each Originator
dishonored Return Entries are accepted, that uses an Unsecured Electronic Network
as required by these rules. Verify that to enter into an Origination Agreement
the ODFI is using return reason codes with the Third-Party Sender. (Article Two,
in an appropriate manner. (Article Two, subsections 2.4.1.8 and 2.15.2)
subsections 2.12.1, 2.12.5.1, and 2.12.5.2;
Appendix Four) j. Verify that Reversing Entries and Reversing
Files are initiated in accordance with the
e. 
Verify that information relating to NOCs requirements of these Rules. (Article Two,
and Corrected NOCs is provided to each sections 2.8 and 2.9)
Originator or Third-Party Sender within two
Banking Days of the Settlement Date of the k. 
For BOC Entries, verify that the ODFI
NOC or Corrected NOC in accordance with has (1) established and implemented
Appendix Five (Notification of Change). commercially reasonable procedures to
Verify that refused NOCs are Transmitted verify the identity of each Originator or
within fifteen (15) days of receipt of an Third-Party Sender of such entries; and (2)
NOC or corrected NOC. (Article Two, established and implemented procedures
subsections 2.11.1 and 2.11.2) to document specific information with
respect to each Originator, as required by
f. With the exception of XCK entries, verify these rules, and that, upon request, such
that the ODFI provides to the RDFI, upon information is provided to the RDFI within
receipt of the RDFI’s written request, the the required time frame. (Article Two,
original, a copy, or other accurate Record subsection 2.5.2.5)
of the Receiver’s authorization with
respect to a Consumer Account within ten l. Verify that the ODFI has reported Return
banking days without charge. (Article Two, Rate information on each Originator
subsections 2.3.2.5 and 2.5.18.6) or Third-Party Sender, as requested by
the National Association. (Article Two,
g. Verify that, when agreed to by the ODFI, late subsection 2.17.2)
Return Entries are accepted in accordance
with these rules. (Article Two, subsection m. 
Verify that the ODFI has (1) registered
2.12.6) its Direct Access status with the National
Association; (2) obtained the approval of
h. 
Verify that the ODFI has provided the its board of directors, committee of the
Originator with proper notice to ensure board of directors, or its designee for
compliance with UCC Article 4A with each Direct Access Debit Participant; (3)
respect to ACH transactions. (Article Two, provided required statistical reporting for
subsection 2.3.3.2) each Direct Access Debit Participant; and
(4) notified the National Association of
i. 
Verify that the ODFI has utilized a any change to the information previously
commercially reasonable method to provided with respect to any Direct Access
establish the identity of each Originator Debit Participant. (Article Two, subsection
or Third-Party Sender that uses an 2.17.1)
Unsecured Electronic Network to enter
into an Origination Agreement with the n. Verify that the ODFI has kept Originators
ODFI. When an ODFI has a relationship and Third-Party Senders informed of their
with a Third-Party Sender rather than responsibilities under these rules. (Article
Two, section 2.1)

2 0 1 3 O P E R AT I N G R U L E S OR199
APPENDIX NINE – Arbitration Procedures

SUBPART 9.2.2  Additional Documents and Fees

The complaint must be accompanied by the
APPENDIX NINE following:
Arbitration SUBPART 9.2.2.1  Documents Relating to Claim
Procedures Copies of the documents available to the
complainant necessary to resolve the dispute and
of any written communications by the complainant
PART 9.1  Scope and the respondent relating to the violation
asserted.
The rules contained in this Appendix Nine govern
the settlement of disputes arising under these
SUBPART 9.2.2.2  Application Fee
Rules between Participating DFIs by arbitration.
In the event of any inconsistency between the A $250 non-refundable application fee to be used
provisions of this Appendix and of Articles One for administrative expenses.
through Eight of these Rules, the provisions of this
Appendix Nine will control. An arbitration claim SUBPART 9.2.3  Authorization for Submitting
a Complaint
under this Appendix Nine will be processed only
if the amount of the damages claimed is $250 or The complaint must be signed by an officer of
more. the complainant and be submitted to the National
Association within two years of the violations
asserted.
PART 9.2  Filing a Complaint
SUBPART 9.2.1  Required Information SUBPART 9.2.4  Complaints Involving Multiple
Participating DFIs
To initiate an arbitration proceeding, a Participating
DFI (the “complainant”) submits a complaint to the If the complainant is involved in related disputes
National Association. A complaint must contain with more than one Participating DFI, a separate
the following: complaint must be filed with respect to each such
Participating DFI.
SUBPART 9.2.1.1  Identification of Parties
The names, addresses and telephone numbers of PART 9.3  Classification of Disputes
the complainant and the other party involved in
SUBPART 9.3.1  Complaints with Damages of
the dispute (the “respondent”).
$250 or More But Less Than $10,000 (Arbitration
Procedure A)
SUBPART 9.2.1.2  Summary of Facts
All complaints in which the amount of damages
A summary of the facts of the dispute as well claimed is $250 or more but less than $10,000
as the section(s) of the Rules that is/are alleged will be processed under Arbitration Procedure A
to have been violated. The summary must also in these rules. Under Arbitration Procedure A: (1)
include information permitting identification of Arbitration is mandatory for both parties once a
the particular transaction(s) and the sequence claim for arbitration is filed in accordance with
of events involved, and the precise nature of the these rules; (2) A hearing will not be held; (3)
violation(s). One arbitrator will decide the case; and (4) The
arbitrator’s stipend will be $100.
SUBPART 9.2.1.3  Statement of Damages
A statement of the dollar amount of damages SUBPART 9.3.2  Complaints with Damages of
claimed by the complainant and an explanation of $10,000 or More But Less Than $50,000
how damages in the amount claimed resulted from (Arbitration Procedure B)
the violation(s) asserted. All complaints in which the amount of damages
claimed is $10,000 or more but less than $50,000
will be processed under Arbitration Procedure B
in these rules. Under Arbitration Procedure B: (1)

OR200 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX NINE – Arbitration Procedures

Arbitration is mandatory for both parties once a the names not deleted on the list returned, or, if
claim for arbitration is filed in accordance with neither list is returned within the time limit, from
these rules; (2) A hearing will not be held; (3) among the names on the lists as mailed to each
Three arbitrators will decide the case; and (4) party.
The stipend for each arbitrator will be 1% of the
arbitrator’s decision. SUBPART 9.4.2  Arbitration Procedures B and C
For claims subject to Arbitration Procedures B and
SUBPART 9.3.3  Complaints with Damages of C, arbitrators will be selected by the following
$50,000 or More (Arbitration Procedure C) method: (1) The National Association will mail
All complaints in which the amount of damages each party the same list of ten arbitrators from
claimed is $50,000 or more will be processed among those nominated as provided herein who
under Arbitration Procedure C in these rules. are not affiliated with either party to the dispute;
Under Arbitration Procedure C: (1) Arbitration (2) Each party will have ten days from the date the
is not mandatory. Before the complaint is filed, list is mailed to review the list, delete three names,
both parties must agree to submit the dispute to and mail or deliver the remaining names to the
arbitration. If both parties agree, one of them must National Association; (3) The National Association
submit to the National Association a complaint that will then compare the two lists and select three
complies with these rules; (2) A hearing will be arbitrators not deleted from either list to decide
held unless the parties otherwise agree and notify the case; and (4) If either list is not returned
the National Association at the time the complaint within the time limit specified above, the National
is filed. If the parties otherwise agree, the Association will then select the arbitrators to
procedures in Subpart 9.5.2 (Arbitration Procedure decide the case from among the names not deleted
B) rather than Subpart 9.5.3 (Arbitration Procedure on the list returned, or, if neither list is returned
C) of this Appendix Nine will be followed; (3) At within that time limit, from among the names on
its discretion, a party may be represented at the the list as mailed to each party.
hearing by legal counsel; (4) Three arbitrators
will decide the case; and (5) The stipend for each PART 9.5  Presentation of the Case and
arbitrator will be 1.5% of the arbitrator’s decision. the Decision

PART 9.4  Selection of Arbitrators SUBPART 9.5.1  Arbitration Procedure A

The National Association will maintain a list Cases subject to Arbitration Procedure A will be
of arbitrators that have been nominated by presented and the decisions reached according
Associations in accordance with the procedures to the following requirements: (1) After a party
established by the National Association. has received notification of the selection of the
arbitrator, it will have 14 days to submit to the
SUBPART 9.4.1  Arbitration Procedure A National Association in writing for consideration in
such proceeding any matter it deems appropriate,
For claims subject to Arbitration Procedure A, an
and the National Association will submit copies
arbitrator will be selected by the following method:
of such materials to the arbitrator and the other
(1) The National Association will mail each party
party; (2) In the event the respondent, in the
the same list of five arbitrators from among
judgment of the arbitrator, fails to cooperate in
those nominated as provided herein who are not
the proceeding within 14 days of a request for
affiliated with either party to the dispute; (2) Each
information by the arbitrator, the facts as stated
party will be given ten days from the date the list
in the complaint will be assumed to be true for
is mailed to review the list, delete two names, and
purposes of the arbitration; (3) Once the arbitrator
mail or deliver the remaining names to the National
has received all information he deems relevant
Association; (3) The National Association will then
or necessary, the arbitrator will have 30 days to
compare the two lists and select one arbitrator not
render his decision. The amount of the award of
deleted from either list to decide the case; and (4)
damages may not exceed the amount of damages
If either list is not returned within the time limit
claimed in the complaint; (4) The arbitrator may
specified above, the National Association will then
adopt such rules and procedures with respect to
select the arbitrator to decide the case from among

2 0 1 3 O P E R AT I N G R U L E S OR201
APPENDIX NINE – Arbitration Procedures

evidence and other procedural and substantive SUBPART 9.5.3  Arbitration Procedure C
matters not inconsistent with these rules as he Cases subject to Arbitration Procedure C will be
may deem appropriate; (5) The decision of the presented and the decisions reached according
arbitrator will be based upon the applicable to the following requirements: (1) If a hearing is
rules; (6) Neither party will initiate contact with to be held, the arbitrators will set a hearing date
the arbitrator concerning the subject matter of which will not be less than 90 days after each
the dispute unless the other party is present; (7) party has received notification of the selection of
The arbitrator will be entitled to recover a part the arbitrators; (2) The National Association will
or all of the arbitrator’s stipend from either party provide both parties with at least 30 days prior
as determined by the arbitrator; and (8) The notice of the hearing; (3) Following the hearing,
arbitrator will pay his expenses and each party the arbitrators will have 30 days to render their
will pay its own expenses, including attorneys’ decision. The amount of the award of damages
fees, in connection with the arbitration. may not exceed the amount of damages claimed in
the complaint; (4) The arbitrators may adopt such
SUBPART 9.5.2  Arbitration Procedure B rules and procedures with respect to evidence
Cases subject to Arbitration Procedure B will be and other procedural and substantive matters not
presented and the decisions reached according inconsistent with these rules as they may deem
to the following requirements: (1) After a party appropriate; (5) The decision of the arbitrators will
has received notification of the selection of the be based upon the applicable rules; (6) Neither
arbitrators, it will have 14 days to submit to the party will initiate contact with any arbitrator
National Association in writing for consideration in concerning the subject matter of the dispute
such proceeding any matter it deems appropriate, unless the other party is present; (7) Each party
and the National Association will submit copies will pay its own expenses, including attorneys’
of such materials to the arbitrators and the other fees, in connection with the arbitration; and (8)
party; (2) In the event the respondent, in the The arbitrators will be entitled to recover a part or
judgment of the arbitrators, fails to cooperate in all of their travel and other expenses in connection
the proceeding within 14 days of a request for with the arbitration and the arbitrators’ stipend
information by the arbitrators, the facts as stated from either party, as determined by the arbitrators.
in the complaint will be assumed to be true for
purposes of the arbitration; (3) Once the arbitrators PART 9.6  Payment and Appeal
have received all information they deem relevant
or necessary, the arbitrators will have 30 days to SUBPART 9.6.1  Arbitration Procedures A and B
render their decision. The amount of the award of Payments of awards and appeals of decisions will
damages may not exceed the amount of damages be subject to the following requirements: (1)
claimed in the complaint; (4) The arbitrators may The party against which such amount has been
adopt such rules and procedures with respect to assessed will have 14 days after receiving notice
evidence and other procedural and substantive of the decision in which to pay the damage award
matters not inconsistent with these rules as they or other amount assessed against it as provided
may deem appropriate; (5) The decision of the in these rules; (2) The decision of the arbitrator(s)
arbitrators will be based upon the applicable will be final and binding on the parties to the
rules; (6) Neither party will initiate contact with dispute, and judgment thereon may be entered
the arbitrators concerning the subject matter of in any court having jurisdiction. Except to the
the dispute unless the other party is present; (7) extent such a prohibition is unlawful under the
The arbitrators will be entitled to recover a part laws of the state in which the party against which
or all of the arbitrators’ stipend from either party damages have been awarded by the arbitrator(s) is
as determined by the arbitrators; and (8) The domiciled, such decision will not be appealable to
arbitrators will pay their expenses and each party the courts.
will pay its own expenses, including attorneys’
fees, in connection with the arbitration. SUBPART 9.6.2  Arbitration Procedure C
Payments of awards and appeals of decisions will
be subject to the following requirements: (1) In

OR202 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TEN – Rules Enforcement

the absence of an appeal to the courts, the party and their customers by limiting the number of
against which such amount has been assessed will unauthorized Entries.
have 14 days after receiving notice of the decision
in which to pay the damage award or other amount PART 10.2  ODFI Reporting
assessed against it as provided in these rules; (2) Requirements
The arbitrators’ decision will be binding on the
parties to the dispute, and judgment thereon may SUBPART 10.2.1  National Association Request
be entered by any court having jurisdiction. Except for Information
to the extent the parties have entered into an If, in its sole discretion, the National Association
enforceable agreement to the contrary, either party believes that the rate that debit Entries are returned
may appeal the arbitrators’ decision to the courts. as unauthorized exceeds one percent for one or
In the absence of such an appeal, the arbitrators’ more Originators or Third-Party Senders using the
decision will be final. ODFI to originate Entries, the National Association
may send, via traceable delivery method, a written
request to the ODFI’s Chief Operating Officer for
information described in Article Two, Subsection
APPENDIX TEN 2.17.2 (ODFI Return Rate Reporting). A copy of
Rules Enforcement this request will also be sent to the ODFI’s ACH
Manager.

SUBPART 10.2.2  National Association Action on

PART 10.1  Scope Receipt of Information Reported by ODFI
Appendix Ten governs the rules enforcement The National Association may initiate a rules
procedures to be applied in the event of (1) enforcement proceeding according to Part 10.4
an ACH rules violation, including a breach (National System of Fines) of this Appendix Ten
of warranty under these rules, filed against a for a Class 2 Rules Violation, as defined within
Participating DFI by a Participating DFI or an ACH Subpart 10.4.7.4 (Class 2 Rules Violation), if the
Operator that is a party to the transaction, (2) the ODFI (1) fails to provide the National Association
identification of a return rate for unauthorized with complete and accurate information, as
Entries by an Originator or Third-Party Sender required by Article Two, Section 2.17.2 (ODFI
that exceeds a defined threshold, or (3) the failure Return Rate Reporting), within ten Banking
of a Participating DFI to comply with a direct Days of receipt of NACHA’s written request for
obligation to the National Association, as defined information; (2) substantiates the claim that the
by these Rules. Originator’s or Third-Party Sender’s return rate
for unauthorized Entries exceeded one percent,
This Appendix Ten (1) defines the criteria under and the ODFI fails to reduce that return rate to a
which a rules enforcement proceeding may be rate below the return threshold for unauthorized
initiated for any violation of these Rules; and Entries within 60 days after receipt of the National
(2) establishes the parameters under which the Association’s written request, according to Article
National Association may undertake specific Two, Section 2.17.2 (ODFI Return Rate Reporting);
actions with respect to the monitoring and or (3) substantiates that the Originator’s or Third-
reporting of activity causing potential harm to Party Sender’s return rate for unauthorized Entries
Participating DFIs or the ACH Network. exceeded one percent, and the ODFI successfully
reduced the return rate to below the return
The purpose of these enforcement mechanisms threshold within the 60 day time period, but the
is to maintain the quality of ACH services and ODFI failed to maintain the return rate below one
the satisfaction of Participating DFIs and their percent for 180 additional days.
customers by promoting compliance with these
rules and reducing the risks to Participating DFIs The National Association may initiate a rules
n

enforcement proceeding according to Part 10.4

nApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR203
 APPENDIX TEN – Rules Enforcement

u (National System of Fines) of this Appendix Ten for of Subpart 10.4.2 (Submission Requirements for
a Class 2 Rules Violation, as defined within Subpart Rules Enforcement Proceedings Initiated by a
10.4.7.4 (Class 2 Rules Violation), if the ODFI Participating DFI or an ACH Operator.) The Report
(1) fails to provide the National Association with of Possible ACH Rules Violation Form and filing
complete and accurate information, as required instructions are located in the NACHA Operating
by Article Two, Section 2.17.2 (ODFI Return Rate Guidelines.
Reporting), within ten Banking Days of receipt
of NACHA’s written request for information; (2) A rules enforcement proceeding may also be
substantiates the claim that the Originator’s or initiated and conducted by the National Association
Third-Party Sender’s return rate for unauthorized in response to (1) a violation of unauthorized
Entries exceeded one percent, and the ODFI fails to Entries according to Part 10.2 (ODFI Reporting
reduce that return rate to a rate below the return Requirements) of this Appendix Ten, or (2) the
threshold for unauthorized Entries within 30 days failure of a Participating DFI to comply with a
after receipt of the National Association’s written direct obligation to the National Association,
request, according to Article Two, Section 2.17.2 as defined by these rules. A rules enforcement
(ODFI Return Rate Reporting); or (3) substantiates proceeding initiated by the National Association
that the Originator’s or Third-Party Sender’s return must comply with the requirements of Subpart
rate for unauthorized Entries exceeded one percent 10.4.3 (Submission Requirements for Rules
and the ODFI successfully reduced the return rate Enforcement Proceedings Initiated by the National
to below the return threshold within the 30 day Association).
time period, but the ODFI failed to maintain the
return rate below one percent for 180 additional SUBPART 10.4.2  Submission Requirements for
days. Rules Enforcement Proceedings Initiated by a
Participating DFI or an ACH Operator
PART 10.3  ODFI Registration Each rules enforcement proceeding initiated by
Requirements a Participating DFI or an ACH Operator that is a
party to a transaction must include a completed
If, in its sole discretion, the National Association
Report of Possible ACH Rules Violation that
believes that an ODFI has failed to register its
includes the following information and conforms
Direct Access Debit Participant status, or to provide
to the following requirements:
data reporting regarding a Direct Access Debit
Participant, the National Association may initiate
SUBPART 10.4.2.1  Identification of Parties
a rules enforcement proceeding. Such proceeding
will be according to Part 10.4 (National System of The names, addresses, and telephone numbers of
Fines) of this Appendix Ten for a Class 2 Rules the complainant and the other Participating DFI
Violation, as defined within Subpart 10.4.7.4 (Class involved in the dispute (the “respondent”) and
2 Rules Violation). routing number of the respondent.

SUBPART 10.4.2.2  Summary of Facts

PART 10.4  National System of Fines
A summary of the facts of the alleged rule violation,
SUBPART 10.4.1  Initiation of a Rules as well as the section(s) of the rules violated. The
Enforcement Proceeding
summary must also include information permitting
A rules enforcement proceeding may be initiated identification of the particular transaction(s), the
for any violation of these rules. A rules enforcement sequence of events involved, the precise nature
proceeding may be conducted by the National of the violation(s), and the consequences to the
Association in response to an ACH rules violation, complainant.
including a breach of warranty under these rules,
filed against a Participating DFI. The complainant SUBPART 10.4.2.3  Documents Relating to Possible
must be a Participating DFI or an ACH Operator Rules Violation
that is party to the transaction. A rules enforcement Copies of the documents available to the
proceeding initiated by a Participating DFI or an complainant necessary to support the claim that
ACH Operator must comply with the requirements

uApproved April 2, 2012, Effective March 15, 2013

OR204 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TEN – Rules Enforcement

an ACH rule has been violated, and of any written the information provided by the ODFI
communications by the complainant and the substantiates that the Originator’s or Third-
respondent relating to the violation(s) asserted. Party Sender’s return rate for unauthorized
Entries exceeded the return rate, and the
SUBPART 10.4.2.4  Authorization for Submitting ODFI successfully reduced the return rate to
a Rules Violation Report below the return threshold within the 60 day
The Report of Possible ACH Rules Violation must time period, but the ODFI failed to maintain
be signed by an authorized representative of the the return rate below the return threshold for
complainant. 180 additional days; (4) or the Participating
DFI failed to comply with a direct obligation
SUBPART 10.4.2.5  Deadline for Submitting a Rules to the National Association, as defined by
Violation Report these rules;
A Report of Possible ACH Rules Violation must
a
u  statement outlining the reason(s) for
be submitted to the National Association within
90 days of the occurrence of the rule violation(s) the initiation of a rules enforcement
asserted. proceeding: (1) the ODFI failed, within the
required timeframe, to provide the National
SUBPART 10.4.2.6  Complaints Involving Multiple
Association with complete and accurate
Participating DFIs information as required by Article Two,
Section 2.17.2 (ODFI Return Rate Reporting);
If the complainant is asserting rules violations
(2) the information provided by the ODFI
against more than one Participating DFI, a separate
substantiates the claim that the Originator
Report of Possible ACH Rules Violation must be
or Third-Party Sender exceeded the return
filed with respect to each such Participating DFI.
rate for unauthorized Entries and the ODFI
has failed to reduce the Originator’s or
SUBPART 10.4.3  Submission Requirements for
Third-Party Sender’s return rate for Entries
Rules Enforcement Proceedings Initiated by the
National Association returned as unauthorized to a rate below the
return threshold for unauthorized Entries
Each rules enforcement proceeding initiated by the
within 30 days after receipt of the National
National Association must contain the following
Association’s written request, according
information and conform to the following
to Article Two, 2.17.2 (ODFI Return Rate
requirements:
Reporting); (3) the information provided by
the ODFI substantiates that the Originator’s
• a statement outlining the reason(s) for
or Third-Party Sender’s return rate for
the initiation of a rules enforcement
unauthorized Entries exceeded the return
proceeding: (1) the ODFI failed, within the
rate, and the ODFI successfully reduced the
required timeframe, to provide the National
return rate to below the return threshold
Association with complete and accurate
within the 30 day time period, but the ODFI
information as required by Article Two,
failed to maintain the return rate below the
Section 2.17.2 (ODFI Return Rate Reporting);
return threshold for 180 additional days; or
(2) the information provided by the ODFI
(4) the Participating DFI failed to comply
substantiates the claim that the Originator or
with a direct obligation to the National
Third-Party Sender exceeded the return rate
Association, as defined by these rules;
for unauthorized Entries and the ODFI has
failed to reduce the Originator’s or Third-
• for a rules enforcement proceeding initiated
Party Sender’s return rate for Entries returned
in response to a violation of unauthorized
as unauthorized to a rate below the return
Entries according to Part 10.2 (ODFI
threshold for unauthorized Entries within 60
Reporting Requirements) of this Appendix
days after receipt of the National Association’s
Ten, a copy of the National Association’s
written request, according to Article Two,
written request for information according to
2.17.2 (ODFI Return Rate Reporting); (3)
Subpart 10.2.1 (National Association Request
for Information) of this Appendix Ten.
uApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR205
APPENDIX TEN – Rules Enforcement

A rules enforcement proceeding initiated by the and explaining that fines may be imposed against
National Association must be submitted within the Participating DFI in the event that the rule
90 days of the occurrence of the rule violation(s) violation is not corrected.
asserted.
The Participating DFI will be asked to correct
SUBPART 10.4.4  Assessment of Rules the problem that caused the rule violation and
Enforcement Submission to respond within ten Banking Days after the
Each submission of a rules enforcement proceeding date on which it received the Notice of Possible
will be evaluated by the National Association to ACH Rules Violation. The Notice of Possible
ensure that the documentation necessary to identify ACH Rules Violation Response Form must be
the incident has been included and to determine sent, via traceable delivery method, to the
whether a violation of these rules appears to have National Association and must include either (1)
occurred. If the National Association makes a an acknowledgment of the Participating DFI’s
preliminary determination that a violation of these recognition of and intent to correct the problem
rules has occurred, the National Association will causing the rule violation, along with a statement
identify whether the violation is (1) the first such specifying the date by which the Participating DFI
violation, (2) a Class 1 Rules Violation involving a will resolve the problem (resolution date), or (2) a
recurrence of a previous violation, or (3) a Class statement, along with supporting documentation,
2 Rules Violation, and it will issue either a Notice that the Participating DFI does not believe that a
of Possible ACH Rules Violation or a Notice of rules infraction has occurred.
Possible Fine in accordance with this Subpart
10.4.4. If the National Association determines that If the National Association receives the
it is unclear whether a rules violation has occurred, Participating DFI’s completed response form
or if the National Association believes the violation and any necessary documentation within the ten
involves a Class 2 Rules Violation, it may forward Banking Day time frame, no additional action will
the issue to the ACH Rules Enforcement Panel for be taken by the National Association unless (1) the
additional review. National Association believes the time frame and
resolution date asserted by a Participating DFI as
In circumstances involving (1) a submission to the necessary to resolve the problem causing the rules
rules enforcement process from a Participating DFI violation are excessive and require review by the
or an ACH Operator that is a party to a transaction, ACH Rules Enforcement Panel, or (2) the National
identifying either a Class 1 Rules Violation or a Association receives an additional submission of a
Class 2 Rules Violation; or (2) a rules enforcement rule violation report.
proceeding initiated by the National Association
because of a Class 2 Rules Violation, the issue SUBPART 10.4.4.2  Notice of Possible Fine
will be forwarded directly to the ACH Rules If the National Association determines that the
Enforcement Panel for evaluation and possible violation is a Class 1, Class 2, or Class 3 Rules
assessment of a fine or penalty in accordance with Violation, as defined by Subpart 10.4.7 (Fines
Subpart 10.4.7 (Fines and Penalties). and Penalties), a Notice of Possible Fine will be
sent to the Participating DFI and the National
SUBPART 10.4.4.1  Notice of Possible ACH Association will forward the issue to the ACH Rules
Rules Violation Enforcement Panel to consider the imposition of a
If the National Association determines that the fine against the Participating DFI in accordance
violation is the first such infraction of these rules, with Subpart 10.4.7 of this Appendix Ten.
a Notice of Possible ACH Rules Violation will
be sent to the ACH Manager at the respondent In the Notice of Possible Fine, the Participating
Participating DFI, within ten Banking Days via DFI will be asked to correct the rule violation that
traceable delivery method, indicating that an is the basis for the Notice of Possible Fine and
infraction of the rules appears to have occurred to respond to the National Association within ten

OR206 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TEN – Rules Enforcement

Banking Days after the date on which it received SUBPART 10.4.5  Notifications
a Notice of Possible Fine. The Notice of Possible
Fine Response Form must be sent, via traceable SUBPART 10.4.5.1  Notification on Initiation of Rules
delivery method, to the National Association and Enforcement Proceeding
must include either (1) an acknowledgment of An informational copy of each rules enforcement
the Participating DFI’s recognition of and intent proceeding initiated under this Appendix Ten will
to correct the problem causing the rule violation be forwarded to the Regional Payments Association
that is the basis for the Notice of Possible Fine, of both the complainant and the respondent. In the
along with a statement specifying the Resolution event that either party is an access participant (i.e.,
Date, or (2) a statement, along with supporting not a member of a Regional Payments Association),
documentation, that the Participating DFI does not an informational copy will be forwarded to the local
believe that a rules violation occurred. Federal Reserve Bank. In situations involving the
initiation of a rules enforcement proceeding by the
Where the ODFI fails to provide a complete National Association according to Subpart 10.4.1
and accurate response in accordance with the (Initiation of a Rules Enforcement Proceeding), an
requirements of Section 2.17.2 (ODFI Return informational copy of each such rules enforcement
Rate Reporting), the ODFI’s acknowledgment proceeding initiated will be forwarded to the ACH
to the Notice of Possible Fine must include the Operators.
reporting information required by Section 2.17.2.
In situations involving the ODFI’s affirmation of a SUBPART 10.4.5.2  Notification on Resolution
return rate for unauthorized Entries in excess of of Issue
the return threshold, the ODFI’s acknowledgment The National Association will notify the complainant
to the Notice of Possible Fine must include upon the resolution of the rules enforcement
updated information on, and the timetable for, the proceeding that either (1) the violation has been
implementation of the ODFI’s plan to reduce its resolved or will be resolved within a certain time
return rate. period, or (2) the respondent has refuted the claim
of a rules violation.
Where the ODFI fails to register or provide data
reporting in accordance with the requirements SUBPART 10.4.6  ACH Rules Enforcement Panel
of Article Two, Section 2.17.1 (Direct Access
Registration), the ODFI’s acknowledgement to the SUBPART 10.4.6.1  Selection of Enforcement Panel
Notice of Possible Fine must include the registration The National Association will maintain a list of
information required by Section 2.17.1. members of the ACH Rules Enforcement Panel
that have been nominated in accordance with the
If the National Association receives the procedures established by the National Association.
Participating DFI’s completed response form
and related information within the ten Banking SUBPART 10.4.6.2  Responsibilities of
Day time frame, and the National Association Enforcement Panel
determines that the response refutes the claim The ACH Rules Enforcement Panel, in accordance
in the Notice of Possible Fine, the National with these rules, is the final authority regarding
Association will take no additional action at that each of these issues:
time. In all other circumstances described within
this Subpart 10.4.4.2, the National Association will • the imposition of any fines or penalties
forward the issue to the ACH Rules Enforcement recommended by the National Association;
Panel for its consideration and possible imposition
of a fine in accordance with Subpart 10.4.7 (Fines • instances in which the National Association
and Penalties) of this Appendix Ten. believes the time frames and Resolution Dates
asserted by the respondent Participating DFI
as necessary to resolve the problem causing
a rules violation are excessive;

2 0 1 3 O P E R AT I N G R U L E S OR207
APPENDIX TEN – Rules Enforcement

• rules violations that the National Association period following the Resolution Date of the
believes constitute Class 1, Class 2, or Class 3 initial rules violation; or
Rules Violations; and
• the same infraction is committed by the same
• situations in which the National Association Participating DFI within the one-year period
determines that it is unclear whether a rules following the Resolution Date of the initial
violation has occurred. rules violation.

SUBPART 10.4.7  Fines and Penalties Fines for recurrences may be assessed by the ACH
Rules Enforcement Panel as follows:
SUBPART 10.4.7.1  Imposition of Fines/Penalties
In the event that a Participating DFI is cited with • The first recurrence of a rules violation that
a Class 1, Class 2, or Class 3 Rules Violation, the will cause a fine to be levied by the National
National Association will impose a fine, subject to Association will result in an assessment of up
approval by the ACH Rules Enforcement Panel, to $1,000 against the Participating DFI.
on the Participating DFI in accordance with this
Subpart 10.4.7. • The second recurrence of a rules violation
that causes a fine to be levied by the National
The National Association will collect a fine by Association will result in an assessment of up
transmitting an ACH debit to the account of the to $2,500 against the Participating DFI.
affected respondent Participating DFI. Each
Participating DFI agrees to the payment of any • The third recurrence of a rules violation that
fines in accordance with this process. The National causes a fine to be levied by the National
Association will provide notice to the respondent Association will result in an assessment of up
Participating DFI of the date and amount of the to $5,000 against the Participating DFI.
debit at least seven Banking Days in advance of
the Settlement Date of the debit. SUBPART 10.4.7.4  Class 2 Rules Violation
A Class 2 Rules Violation is one in which:
SUBPART 10.4.7.2  Determination of Fines
The fine(s) levied against a respondent (1) 
the Participating DFI has not responded
Participating DFI for an infraction(s) of these rules to either the Notice of Possible ACH Rules
will be determined based on an evaluation by the Violation or the Notice of Possible Fine;
National Association of whether the rules violation
is a Class 1, Class 2, or Class 3 Rules Violation. (2) 
the Participating DFI responds to either
notice that it does not intend to correct the
SUBPART 10.4.7.3  Class 1 Rules Violation rules violation;
A Class 1 Rules Violation involves a recurrence
(3) 
the Participating DFI (i) fails to respond
of a previous rules violation. A rules violation
completely and accurately, within the proper
is considered to be a recurrence of a previously
time frame, to the National Association’s
reported infraction of these rules if:
request for information in accordance with
the requirements of Article Two, Section
• the same infraction is committed by the same
2.17.2 (ODFI Return Rate Reporting); (ii)
Originator that transmits through the ODFI
substantiates the claim that the Originator
within the one-year period following the
or Third-Party Sender exceeded the return
Resolution Date of the initial rules violation;
rate for unauthorized Entries and the ODFI
has failed to reduce the Originator’s or
• the same infraction is committed by the same
Third-Party Sender’s return rate for Entries
Third-Party Service Provider transmitting
returned as unauthorized to a rate below
through or on behalf of an ODFI or receiving
the return threshold for unauthorized
on behalf of an RDFI within the one-year

OR208 2 0 1 3 O P E R AT I N G R U L E S
 APPENDIX TEN – Rules Enforcement

Entries within 60 days of receipt of the (4) 

the Participating DFI fails to register its
National Association’s written request; Direct Access Debit Participant status
or (iii) substantiates that the Originator’s or provide data reporting on a Direct
or Third-Party Sender’s return rate for Access Debit Participant, as required by
unauthorized Entries exceeded the return Article Two, Section 2.17.1 (Direct Access
rate, and the ODFI successfully reduced the Registration);
return rate to below the return threshold
within the 60 day time period, but the ODFI (5) 
the Participating DFI fails to provide
failed to maintain the return rate below the the National Association with proof of
return threshold for 180 additional days. completion of a rules compliance audit,
The Panel may consider the Originator’s as required by Appendix Eight (Rule
or Third-Party Sender’s volume of debit Compliance Audit Requirements);
Entries as an extenuating circumstance
in determining whether a violation under (6) 
the ACH Rules Enforcement Panel
this provision constitutes a Class 2 Rules determines the time frame and resolution
Violation. date asserted by a Participating DFI as
necessary to resolve the problem causing
u (3) the Participating DFI (i) fails to respond the rules violation are excessive;
completely and accurately, within the proper
time frame, to the National Association’s (7) the National Association believes that the
request for information in accordance with violation causes excessive harm to one
the requirements of Article Two, Section or more Participating DFIs or the ACH
2.17.2 (ODFI Return Rate Reporting); (ii) Network; or
substantiates the claim that the Originator
or Third-Party Sender exceeded the return (8) it is the fourth or subsequent recurrence of
rate for unauthorized Entries and the ODFI the same rules violation.
has failed to reduce the Originator’s or
Third-Party Sender’s return rate for Entries In situations involving a Class 2 Rules Violation,
returned as unauthorized to a rate below the ACH Rules Enforcement Panel may levy a
the return threshold for unauthorized fine against the respondent Participating DFI in
Entries within 30 days of receipt of the an amount up to $100,000 per month until the
National Association’s written request; problem is resolved. Where the violation relates
or (iii) substantiates that the Originator’s to a specific Originator or Third-Party Service
or Third-Party Sender’s return rate for Provider at the DFI, a separate monthly fine may
unauthorized Entries exceeded the return be assessed to the DFI with respect to each such
rate, and the ODFI successfully reduced the Originator or Third-Party Service Provider.
return rate to below the return threshold
within the 30 day time period, but the ODFI SUBPART 10.4.7.5  Class 3 Rules Violation
failed to maintain the return rate below the In any case where a Class 2 Rules Violation,
return threshold for 180 additional days. as defined by Subpart 10.4.7.4 (Class 2 Rules
The Panel may consider the Originator’s Violation), has continued for three consecutive
or Third-Party Sender’s volume of debit months, the ACH Rules Enforcement Panel
Entries as an extenuating circumstance may determine that the violation of these rules
in determining whether a violation under by a respondent Participating DFI is a Class 3
this provision constitutes a Class 2 Rules Rules Violation and may levy a fine against the
Violation. respondent Participating DFI of up to $500,000
per month until the problem causing the violation
is resolved.

uApproved April 2, 2012, Effective March 15, 2013

2 0 1 3 O P E R AT I N G R U L E S OR209
APPENDIX TEN – Rules Enforcement

SUBPART 10.4.7.6  Suspension

In circumstances where the ACH Rules Enforcement
Panel has determined that there is a Class 3 Rules
Violation that relates to a specific Originator or
Third-Party Sender according to Subpart 10.4.7.5
(Class 3 Rules Violation) of this Appendix Ten, the
ACH Rules Enforcement Panel may direct the ODFI
to suspend the Originator or Third-Party Sender
from originating. Any such suspension shall only
be lifted by the ACH Rules Enforcement Panel.

In cases where the ACH Rules Enforcement Panel

has directed an ODFI to suspend an Originator or
Third-Party Sender from originating, the National
Association will provide notice of such suspension,
and any subsequent reinstatement, to Participating
DFIs, ACH Operators, and Regional Payments
Associations.

OR210 2 0 1 3 O P E R AT I N G R U L E S
 INDEX

Index

NACHA Operating Rules

A Acknowledgment entries, OR185

codes for refused acknowledgment entries,
Acceptance of return entries, OR27 OR185
Accountability for entries, OR52 defined, OR52
Account closed code, OR127 record formats, OR185–OR191
Account frozen code, OR130 refused, OR28, OR185
Account holder death standard entry class code, OR120
account holder deceased code, OR129 Addenda record
Accounting information. See Automated addenda information, OR102
accounting advice addenda record indicator, OR102
Account numbers addenda sequence number, OR103
posting entries, OR33 addenda type code, OR103
Account sold to another DFI code, OR129 defined, OR53
Accounts receivable entries file structure, OR63
authorization requirements, OR9 ADV. See Automated accounting device
defined, OR52 Advice routing number, OR103
improper debit, OR43 Alphameric, OR62
notification, OR9 Amendment of the Rules, OR2
obligations of originators, OR9, OR10 American National Standards Institute, OR14,
origination of, OR4–OR6 OR16, OR19, OR113
payment information retention, OR10 Amount, OR103
receiver’s written statement, OR43–OR44 ANSI. See American National Standards Institute
requirements for MICR capture, OR9 ANSI ASC X12.5/X12.6
right to recredit, OR42–OR43 defined, OR116
sequence of records, OR79 Appeals, OR202
standard entry class code, OR121 Application Control Structure
warranties, OR10 defined, OR116
Accredited Standards Committee X12 Arbitration. See Compensation
PIN requirements, OR14, OR16, OR19 arbitration procedures, OR200
ACH File filing a complaint, OR200
acknowledgment, OR68 ARC Entries. See Accounts receivable entries
correcting, OR54 Article 4A
defined, OR56 defined, OR53
exchange specifications, OR62 ASC X12. See Accredited Standards Committee
format data elements, OR102–OR125 X12
reversing, OR24 Association. See also National Automated
structure, OR63 Clearing House Association
ACH Operators. See Automated Clearing House defined, OR53
Operators designated data, OR50–OR51
ACH Rules Enforcement Panel, OR207 indemnity, OR51
ACK entries. See Acknowledgment entries ATX entries. See Financial EDI acknowledgment
entries

2 0 1 3 O P E R AT I N G R U L E S OR211
INDEX

Audit requirements B
all DFIs, OR195
general rule, OR1, OR195 Back office conversion entries
ODFIs, OR198–OR199 defined, OR53
RDFIs, OR196–OR198 improper debits, OR43
rules compliance audit requirements, OR195 notification, OR10
Third-Party Service Providers, OR195, OR198 obligations of Originators, OR10–OR11
Authorization, OR5–OR6 origination of, OR10, OR10–OR11
authorization code, OR104–OR105 right to recredit, OR42
Automated accounting advice sequence of records, OR80
ACH Operator obligations, OR48 specific provisions for, OR10–OR11
defined, OR53 standard entry class codes, OR121
file record format, OR77–OR78 Back valuation
standard entry class code, OR120 defined, OR193
Automated Clearing House Banking Day
defined, OR53 defined, OR53
Automated Clearing House Operators Batch count, OR104
adherence to NACHA Operating Rules, OR46 Batch level reject option, OR69
agreement, OR46 Batch number, OR104
agreements with DFIs, OR46 Beginning segment for payment order/
data elements, OR102 remittance advice
defined, OR53 defined, OR116
Federal Reserve Policy Statement on Privately Beneficiary, change of, OR194–OR195
Operated Multilateral Settlement Systems, Beneficiary deceased code, OR129
OR46 Block count, OR104
file reversals, OR47–OR48 Blocking factor, OR104
general responsibilities, OR46 BOC. See Back office conversion entries
general rules, OR1 BPR/BPS data segment
indemnity of association, OR51 defined, OR116
inter-ACH Operator exchange, OR46 Business day
limitation of liability, OR51 defined, OR53
not agent of participating DFI, OR47
performance standards, OR46 C
processing functions, OR46
record of entries requirement, OR2 Card expiration date, OR104
record retention, OR47 Card transaction type code, OR104
return entries, OR47 CCD entries. See Corporate credit or debit entries
return or rejection by, OR46 Change codes, OR104
risk control measures, OR46 table of, OR168–OR172
Automated enrollment entries Change of beneficiary, OR194
about, OR13 Check
defined, OR53 defined, OR53
return by Federal Government Agency codes, Check digit, OR104
OR136 Check serial number, OR105
sequence of records, OR85 defined, OR53
standard entry class code, OR121 Check truncation entries. See Truncated check
Automatic batch rejection, OR69–OR70 entries
Automatic entry detail rejection, OR70–OR72 Check truncation program
Automatic file rejection, OR68–OR69 defined, OR53
Auxiliary on-us field Code values, OR73
defined, OR53 Company/batch control record
Availability, OR35 entry hash, OR109–OR110
format specifications, OR73

OR212 2 0 1 3 O P E R AT I N G R U L E S
 INDEX

Company/batch header record Credit entry refused by receiver code, OR132

acknowledgment entries, OR185 Crediting entries, OR35
contested dishonored returns, OR163 CTX entries. See Corporate trade exchange entry
dishonored returns, OR158 Customer advises not authorized code, OR128,
format specifications, OR73, OR75–OR76 OR133
international ACH transactions, OR76, OR148, Customer initiated entry, OR12
OR175 addenda record, OR82
notification of change, OR174 defined, OR54
refused notification of change, OR181 sequence of records, OR66, OR82
returns, OR147 standard entry class code, OR121
specifications, OR62–OR63 Customer service telephone number
Company descriptive date, OR105 back office conversion entries, OR11
Company discretionary data, OR105
Company entry description, OR105
Company identification, OR106
D
Company name, OR106 Data acceptance specifications, OR68
Compensation rules, OR192 Data elements, OR102–OR125
Complaints. See Arbitration Data set label configuration, OR68
Construction, rules of, OR2 Data specifications, OR62
Consumer accounts alphameric, OR62
authorizations and notices, OR5 numeric, OR62
defined, OR54 Date of death, OR107
notices of variable debits, OR6 Date of rules, OR2
stop payment affecting, OR197 Date original entry returned, OR107
Contested dishonored return, OR28, OR41, OR162 Death notification entries, OR13
record format, OR163–OR166 defined, OR54
Contested dishonored return reason code, OR107 sequence of records, OR84
Copying items, OR18, OR23 standard entry class code, OR121
Corporate credit or debit entry Debit authorization, OR6
defined, OR54 Debit entries, OR6, OR194
sequence of records, OR66 change of beneficiary, OR194
standard entry class code, OR121 Debiting date change, OR7
Corporate entry detail record. See Entry detail Debits
record Direct Access registration, OR31
acknowledgment entries, OR188 preauthorized bill payment, OR17
contested dishonored returns, OR164 Defenses, OR18, OR23
dishonored returns, OR159 Definitions of terms, OR52–OR60
file structure, OR63 Delays
notification of change, OR176 excused, OR3
refused notification of change, OR182 six banking days, OR24
return entries, OR149 unexcused, OR3
Corporate trade exchange entry Deposit Insurance Assessment, OR192
defined, OR54 Depository Financial Institutions. See
sequence of records, OR67 also Originating Depository Financial
standard entry class code, OR121 Institutions; See also Receiving Depository
Corrected data, OR107 Financial Institutions
Correcting file, OR24, OR47 account number, OR107
defined, OR54 audit requirements, OR195–OR196
CORS. See Notifications of change; See Automated risk assessments, OR1
notifications of change; See Refused settlement and accountability, OR51
notifications of change Designated data
COR trace sequence number, OR107 defined, OR54
Credit entries Destroyed check entries
change of beneficiary, OR194 defined, OR54
choice of law, OR3 origination, OR22
returned, OR40 return code, OR133
unposted, OR40 standard entry class code, OR122

2 0 1 3 O P E R AT I N G R U L E S OR213
INDEX

DFI account number, OR107, OR111 Entry detail records. See also Corporate entry
DFIs. See Depository Financial Institutions detail record
Direct access acknowledgement entries, OR187
defined, OR54 contested dishonored returns, OR165
registration, OR31–OR32 dishonored returns, OR160
Direct access debit participant exchange specifications, OR62
defined, OR54 format specifications, OR73
Direct Financial Institution notification of change, OR177
defined, OR54 refused acknowledgment entries, OR190
Discretionary data, OR107 refused notification change, OR183
Dishonored returns returns, OR150
codes used by ODFIs, OR139–OR140 Entry detail sequence number, OR109
contested, OR41 Entry hash, OR109–OR110
corrected, OR40 Erroneous entries, OR193–OR194
ODFIs, OR28 defined, OR55
reason code, OR108 Erroneous file
record format, OR158–OR161 defined, OR56
settlement date, OR108 Excused delay, OR3
specifications, OR157 Existing relationship
trace number, OR108 defined, OR56
Disputes. See Arbitration Exposure limits, OR5
DNE entries. See Death notification entries Extended return entries, OR45–OR46
Document reference number, OR108 defined, OR56
Duplicate enrollment code, OR137
Duplicate entry code, OR132
Duplicate return code, OR139
F
Federal funds rate
E defined, OR192
Federal Reserve Bank, OR51–OR52
Effective entry date, OR108 FGO. See Foreign Gateway
Effect of illegality Field error codes, OR102, OR140
rules compliance, OR1 Field inclusion requirements, OR102
Electronic File
defined, OR54 defined, OR56
Electronic Record File acknowledgment
defined, OR54 ACH Operators, OR68
records permitted, OR3 File control record
Electronic signature entries format, OR73
defined, OR55 entry hash, OR109
Electronic transmission requirements, OR62 format specifications, OR74
Eligible item, OR17, OR22 specifications, OR65
Eligible source document File creation date, OR109
defined, OR55 File creation time, OR109
Encoding, OR19 File header records
Endorsement exchange specifications, OR63
restrictive, OR18 format specifications, OR74
ENR entries. See Automated enrollment entries File identification, OR109
Entries File ID modifier, OR109
defined, OR55 File level reject option, OR69
general rules, OR1 File record edit criteria code, OR130
reversing, OR25–OR26 File specification, OR62–OR67
timeliness of, OR8, OR46 Financial agency
transmission of, OR8 defined, OR56
Entry/addenda count, OR108 Financial Crimes Enforcement Network,
U.S. Department of Treasury, OR1

OR214 2 0 1 3 O P E R AT I N G R U L E S
 INDEX

Financial EDI acknowledgment entries Immediate destination, OR111

defined, OR52 Immediate destination name, OR111
format specifications, OR188 Immediate origin, OR112
standard entry class code, OR121 Immediate origin name, OR112
FINCEN. See Financial Crimes Enforcement Improper source document code, OR135
Network, U.S. Department of Treasury Inbound IAT entries
Fines debit, OR49
national system, OR204–OR206 defined, OR56
Foreign Correspondent Bank warranties, OR49
defined, OR56 Incomplete transaction
Foreign Correspondent Bank branch country defined, OR56
code, OR109 Indemnification
Foreign Correspondent Bank identification reversing entries, OR25
number, OR110 reversing files, OR47
Foreign Correspondent Bank identification Individual card account number, OR112
number qualifier, OR110–OR111 Individual identification number, OR112, OR116
Foreign Correspondent Bank name, OR110 Individual name, OR112
Foreign exchange indicator, OR110 Ineligible item code, OR138
Foreign exchange reference, OR110 Information release, OR30, OR35
Foreign exchange reference indicator, OR110 Insolvency. See Knowledge of insolvency
Foreign Gateway Insufficient funds
defined, OR56 return reason code, OR127
Foreign payment amount, OR110 Interchange Control Structure
Foreign payment system rules, OR13 defined, OR116
Foreign receiver’s account number, OR111 International ACH transactions
Foreign Receiving DFI codes, OR144 addenda records for returns, OR153–OR156
Foreign trace number, OR111 company/batch header record format, OR76
Format code, OR111 defined, OR56
Format specification requirements, OR73 entry detail record, OR86
Forward valuation, OR193 entry detail record for returns, OR152
Fraud detection systems, OR22 Gateway Operators rules, OR48–OR50
indicator, OR111
notifications of change, OR175, OR179
G origination of entries, OR13
Gateway right to recredit, OR42
defined, OR56 sequence of records, OR67, OR86–OR90
GO identification/originating DFI standard entry class code, OR121
identification, OR111 Internet-initiated/mobile entries
GO identification/receiving DFI identification, annual audits, OR22
OR111 defined, OR57
international ACH transactions, OR48–OR50 identity verification, OR22
operator OFAC screening indicator, OR111 obligations of originators, OR22
Glossary of data elements, OR102–OR125 origination of, OR21
Good title, OR18, OR23 routing number verification, OR22
sequence of records, OR66, OR100
standard entry class code, OR122
I Interpretation of the Rules, OR2
Invalid account number code, OR127
IAT. See International ACH transactions Invalid company identification code, OR131
IAT indicator, OR111 Invalid individual ID number code, OR131
Identification number, OR111 ISO destination country code, OR113
Identity verification ISO destination currency code, OR113
back office conversion entries, OR11 ISO originating currency code, OR113
Internet-initiated entries, OR22 Item research number, OR113
telephone-initiated entries, OR21 Item type indicator, OR113
Third-Party Senders, OR11

2 0 1 3 O P E R AT I N G R U L E S OR215
INDEX

J Non-participant in IAT program return code,

OR143
Julian date on which advice is created, OR113 Non-settled entries
ACH Operator obligations, OR52
K defined, OR57
Non-transaction account code, OR131
Knowledge of insolvency, OR19, OR23 Notifications of change, OR167
change codes, OR168–OR172
company/batch header records, OR174–OR175
L defined, OR57
ODFI and originator action, OR27
Legal requirements
ODFIs responsibilities, OR27–OR28
defined, OR57
RDFI responsibilities, OR41
RDFI warranties, OR41
M record formats, OR173–OR184
refused, OR167
MAC. See Message authentication code refused COR code, OR119
Machine transfer entries six banking days’ delay, OR24
defined, OR57 standard entry class code, OR121
PIN requirements, OR14 Number of addenda records, OR113
rules application, OR14 Numeric, OR62
sequence of records, OR91
standard entry class code, OR121
Message authentication code, OR113 O
MICR
ODFI. See Originating Depository Financial
defined, OR57
Institution
Misconduct of ACH Operators, OR51
OFAC. See Office of Foreign Assets Control
Misrouted return code, OR139
Office of Foreign Assets Control, OR1
MTE. See Machine transfer entries
screening indicators, OR111
Optional services, OR48
N Organization
defined, OR57
NACHA Operating Rules Original entry trace number, OR113
ACH Operators adherence, OR46 Original forward entry payment amount, OR114
defined, OR60 Original receiving DFI identification, OR114
National Association Original settlement date, OR114
defined, OR57 Originating Automated Clearing House Operator
information requirements, OR48 defined, OR57
protection from frivolous lawsuits, OR3 Originating Depository Financial Institution
reports to, OR31–OR32 audit requirements, OR198
rules violations and, OR203–OR209 defined, OR57
National System of Fines dishonor of return entries, OR28
ACH Rules Enforcement Panel, OR207 documentation of originators, OR11
assessment of rules enforcement submission, effect of closing on time of settlement, OR52
OR206 exposure limits, OR5
fines and penalties, OR208 non-settled entries, OR52
initiation of rules enforcement proceeding, notice by, OR5–OR6
OR204 notifications of change, OR27
reporting violations, OR204–OR205 payment to, OR30
Network Administration Fees, OR4 recalls, OR24
Network identification code, OR113 reporting requirements, OR31
No account/unable to locate account code, OR127 request for return, OR27
NOC. See Notifications of change restrictions on data passing, OR7
No error found code, OR142 return entries, OR27–OR28
Non-monetary entry rules compliance, OR195
defined, OR57

OR216 2 0 1 3 O P E R AT I N G R U L E S
 INDEX

warranties of, OR7–OR8, OR10, OR11–OR12, P

OR13, OR16, OR18, OR20, OR22, OR23,
OR26 Participating Depository Financial Institution
Originating DFI branch country code, OR114 audit requirements, OR195–OR196
Originating DFI identification, OR114 defined, OR58
Originating DFI identification number qualifier, Payment Association
OR114 defined, OR53
Originating DFI name, OR114 Payment related information, OR34,
Origination agreement OR115–OR117
defined, OR58 Payment type code, OR117
Origination of entries Periodic statements, OR12
accounts receivable entries, OR9 Permissible return entry codes, OR133, OR140
automated enrollment entries, OR13 Person
back office conversion entries, OR10 defined, OR58
check truncation entries, OR21 Personal identification numbers
corporate credit or debit entries, OR12 requirements, OR14, OR16, OR19
corporate trade exchange entries, OR12 PIN numbers. See Personal identification
customer initiated entries, OR12 numbers
death notification entries, OR13 Point-of-purchase entries
destroyed check entries, OR22 defined, OR58
indemnity of ODFIs, OR9 notification, OR15
international ACH transaction entries, OR13 origination of entries, OR15–OR17
internet-initiated/mobile entries, OR21 receiver’s written statement, OR15
machine transfer entries, OR14 right to recredit, OR42
point-of-purchase entries, OR15 sequence of records, OR92
point-of-sale entries, OR16 standard entry class code, OR121
prearranged payment and deposit entries, Point of sale entries
OR17 defined, OR58
prenotifications, OR24 PIN requirements, OR16
prerequisites, OR4–OR6 sequence of records, OR93
reclamation entries, OR25–OR26 standard entry class code, OR122
reinitiation of returned entries, OR28 Prearranged payment and deposit entries
re-presented check entries, OR17–OR19 defined, OR58
reversing entries, OR25–OR26 sequence of records, OR94
reversing files, OR24 standard entry class code, OR122
shared network entries, OR19–OR20 Prenotification entries
telephone-initiated entries, OR19–OR20 defined, OR58
warranties of ODFIs, OR7–OR8 general rule, OR24
Originator city and state/province, OR115 RDFIs, OR38
Originator country and postal code, OR115 Priority code, OR117
Originator identification, OR115 Process control field, OR117
Originator name, OR115 Processing obligations, OR46–OR47
Originators
defined, OR58 R
Third-Party Sender as, OR4
verification of originator identity, OR11 RCK entries. See Re-presented check entry
Originator status code, OR68, OR115 RDFIs. See Receiving Depository Financial
Originator street address, OR115 Institution
Outbound IAT entries Recalling entries, OR24
authorization, OR13 Receipts
defined, OR58 point-of-purchase entries, OR15
warranties, OR13, OR49 Receiver
defined, OR58
Receiver city and state/province, OR118
Receiver country and postal code, OR118
Receiver identification number, OR118

2 0 1 3 O P E R AT I N G R U L E S OR217
INDEX

Receiver street address, OR118 Reporting requirements

Receiving Automated Clearing House Operator ODFIs, OR31–OR33, OR203
defined, OR59 Reports
Receiving company name, OR118 to National Association, OR31–OR33
Receiving company name/ID number, OR118 Representative payee deceased code, OR129
Receiving company name/individual name, Re-presented check entry
OR118 defined, OR58
Receiving Depository Financial Institution general rule, OR17
defined, OR59 notification, OR17
notice to receiver, OR34 obligations of originators, OR18
notification of change, OR41 origination, OR17–OR18
warranties, OR35 sequence of records, OR95
Receiving DFI branch country code, OR118 standard entry class code, OR122
Receiving DFI identification, OR111, OR118 state law affecting acceptance code, OR138
Receiving DFI identification number qualifier, Request for return, OR27
OR119 Restrictive endorsements, OR18
Receiving DFI name, OR119 Returned per ODFI’s request code, OR127
Receiving point Return entries, OR126
defined, OR59 acceptance, OR27
Reclamation entry addenda records, OR151
defined, OR59 company/batch header record, OR147
Records. See also Electronic signature contested dishonored, OR28
code values, OR119 defined, OR59
defined, OR59 dishonored, OR28
electronic, OR3 entry detail records, OR150
formats, OR73–OR101 extended, OR45–OR46
of entries, OR2, OR47 RDFI’s right to transmit, OR39–OR41
retention, OR2 record formats, OR146–OR156
return entry formats, OR146–OR156 reinitiation, OR28
Record sequence in files, OR62–OR63 request for return, OR27
Record size, OR119 six banking days’ delay, OR24
Record type code, OR119 table of return reason codes, OR127–OR145
Recredit right not exclusive, OR43 Return fee, OR29–OR30
Recredit rights, OR42–OR43 defined, OR59
Reference code, OR119 Return fee entry, OR29–OR30
Reference information, OR119 defined, OR60
Refused acknowledgment code, OR119 Return reason code, OR119
Refused acknowledgment entries, OR185 table of return reason codes, OR127–OR145
record formats, OR185, OR189–OR191 Return settlement date, OR119
Refused COR code, OR119 Return trace number, OR120
Refused notifications of change. See Notifications Reversals
of change defined, OR60
Regulation CC Reversing entries, OR25–OR26
defined, OR59 defined, OR60
Regulation D Reversing files, OR24
defined, OR59 ACH Operators, OR47
Regulation E defined, OR60
defined, OR59 Right to recredit, OR42
Reinitiation of returned entries by originators, Right to return entries, OR39–OR41
OR28 Risk assessments, OR1
Reject Routing number of ACH operator, OR120
defined, OR59 Routing number verification, OR21, OR22
Rejected entries Rules amendment, OR2
by ACH Operator, OR46 Rules, beneficiaries of, OR3
check truncation entries, OR47 Rules enforcement, OR1, OR203–OR209
Rules violations, OR203–OR209

OR218 2 0 1 3 O P E R AT I N G R U L E S
 INDEX

S Telephone-initiated entries
authorization for, OR20–OR21
Secondary OFAC screening indicator, OR120 defined, OR60
Security requirements. See Data security general rule, OR19
requirements obligations of originators, OR20
Sending points sequence of records, OR97
defined, OR60 standard entry class code, OR122
liabilities of ODFIs, OR5 Terminal city, OR122
Sequence number within batch, OR120 Terminal identification code, OR122
Sequence of records, OR62–OR63 Terminal location, OR123
Service class code, OR120 Terminal state, OR123
Settlement, OR51–OR52 Third-Party Senders
Settlement date, OR120–OR121 agreements with ODFIs, OR4–OR5
defined, OR60 defined, OR60
Shared network entries international ACH transactions, OR13
defined, OR60 obligations of, OR30–OR31
general rule, OR19 risk management of, OR5
PIN requirements, OR19 verification of identity, OR8
sequence of records, OR96 Third-Party Service Providers
standard entry class code, OR122 defined, OR60
SHR. See Shared network entries Timely original return code, OR141
Single entry Total amount, OR123
defined, OR60 Total debit or credit entry dollar amount, OR123
Six banking days’ delay, OR24 Trace number, OR123–OR124
Source documents Trace number sequence, OR65
accounts receivable entries, OR9 Transaction account
back office conversion entries, OR11 defined, OR60
defined, OR55 Transaction codes, OR123–OR124
improper source document code, OR135 Transaction date, OR124
may not be presented for payment, OR10, Transaction description, OR124
OR11 Transaction serial number, OR125
point-of-purchase entries, OR15 Transaction time, OR125
presented for payment code, OR134 Transaction type code, OR125
stop payment code, OR134 Transmit
Standard Entry Class Codes, OR120–OR122 defined, OR60
defined, OR60 TRC entries. See Truncated check entries
RDFI may rely on, OR33 Truncated check entries
State law affecting acceptance code, OR138 defined, OR53
Statements, periodic, OR12 eligible participants, OR21
Stop payment codes, OR128, OR134, OR138 return and rejection, OR47
Stop payments, OR38–OR39 return code, OR129
rules application, OR21
T sequence of records, OR98
standard entry class code, OR122
Technical specifications Truncated entries exchange
ACH file exchange, OR62–OR67 defined, OR53
ACH record format, OR73–OR125 rules application, OR21
acknowledgment entries, OR185–OR191 sequence of records, OR99
arbitration procedures, OR200–OR202 standard entry class code, OR122
compensation rules, OR192–OR194 Truncation
data acceptance, OR68–OR72 defined, OR61
national system of fines, OR204–OR209 TRX. See Truncated entries exchange
notification of change, OR167–OR184
return entries, OR126–OR166
rule compliance audit requirements,
OR195–OR199
rules enforcement, OR203–OR209

2 0 1 3 O P E R AT I N G R U L E S OR219
INDEX

U W
UEN. See Unsecured electronic networks Waiver of right to recredit, OR43
Unable to locate account code, OR127 Warranties
Uncollected funds code, OR128 destroyed check entries, OR23
Unexcused delays, OR3 liability for breach of, OR9
Uniform Commercial Code of Gateway, OR49
defined, OR61 of ODFIs, OR7–OR8
Unposted credit entries, OR40 of RDFIs, OR35
Unsecured electronic networks sending points, OR8
defined, OR61 Third-Party Senders, OR30
transmission of ACH information, OR3 Wireless network
warranties, OR8 defined, OR61
Untimely return code, OR139 Written statement of unauthorized debit
defined, OR61
V
Variable debits, OR6

OR220 2 0 1 3 O P E R AT I N G R U L E S
NACHA Operating Guidelines –
Corporate Edition
The NACHA Operating Rules (Rules) provides users with the legal framework for the ACH
Network, while the NACHA Operating Guidelines – Corporate Edition provides guidance on
implementing the rules. In the case of any inconsistency or conflict between the Rules and the
NACHA Operating Guidelines – Corporate Edition, the NACHA Operating Rules govern.

The NACHA Operating Guidelines - Corporate Edition includes excerpts from the NACHA
Operating Guidelines that are important to corporations. Refer to the Guidelines for originator
roles and responsibilities within the ACH Network and an overview of various Standard Entry
Class Codes. In addition, the NACHA Operating Guidelines – Corporate Edition offers details on
the legal framework of the Rules, Third-Party Service Providers, OFAC Compliance, and a brief
history of the development of the ACH Network.

Users of the corporate edition of the NACHA Operating Rules & Guidelines should be aware that
certain chapters and/or section of the NACHA Operating Guidelines have been omitted from this
document. Additional topics not addressed by this corporate edition and other important, more
detailed information relating to the processing of ACH entries by both Originators and other
ACH participants may be found within the complete NACHA Operating Guidelines contained
within the 2013 NACHA Operating Rules & Guidelines.
 SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

ACH PARTICIPANTS
SECTION I Listed below, and in Figure 1-1, are the participants
that are involved in a typical ACH transaction:

General 1. 
the originating company or individual

Information
(Originator),

2. the Originating Depository Financial Institution

(ODFI),

3. the ACH Operator,

CHAPTER 1 4. the Receiving Depository Financial Institution

Overview of the System (RDFI),

5. the receiving company, employee or customer

The ACH Network is a batch processing system. (Receiver), and
Rather than sending each payment separately,
financial institutions accumulate ACH transactions 6. the Third-Party Service Provider (optional).
and sort them by destination for transmission
during a predetermined time period. This Originator
provides significant economies of scale and faster The Originator is the entity that agrees to initiate
processing than checks. Instead of using paper ACH entries into the payment system according to
to carry necessary transaction information, ACH an arrangement with a Receiver. The Originator is
transactions are transmitted electronically between usually a company directing a transfer of funds to or
financial institutions through data transmission. from a consumer’s or another company’s account.

FIGURE 1-1  ACH PARTICIPANTS

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG1
SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

In the case of a customer initiated entry, however, Third-Party Service Provider

the Originator may be an individual initiating In some instances, an Originator, ODFI, or RDFI may
funds transfer activity to or from his or her own choose to use the services of a Third-Party Service
account. The term “company” is representative of Provider for all or part of the process of handling
the Originator of electronic ACH entries and does ACH entries. A Third-Party Service Provider is an
not imply exclusion of other types of organizations, entity other than the Originator, ODFI, or RDFI that
such as a charity or government entity. performs any functions on behalf of the Originator,
ODFI, or RDFI with respect to the processing of
Originating Depository Financial Institution ACH entries. A function of ACH processing can
The Originating Depository Financial Institution include, but is not limited to, the creation of ACH
(ODFI) is the institution that receives the payment files on behalf of an Originator or ODFI, or acting
instructions from Originators and forwards the as a Sending Point or Receiving Point on behalf of
entries to the ACH Operator. A Depository Financial an ODFI or RDFI, respectively.
Institution may participate in the ACH Network as
a Receiving Depository Financial Institution (RDFI) A particular type of Third-Party Service Provider
without being an ODFI; however, if a DFI chooses is the Third-Party Sender. A Third-Party Sender
to originate ACH entries, it must also agree to act acts on behalf of the Originator when there is no
as an RDFI. agreement between the ODFI and Originator for
ACH origination services.
ODFIs are discussed in detail in Section II of
these Guidelines. As the ACH Network continues to evolve, Third-
Party Service Providers have taken on larger and
Automated Clearing House Operator more complex roles in the processing of ACH
An Automated Clearing House (ACH) Operator transactions.
is a central clearing facility that receives entries
from ODFIs, distributes the entries to appropriate For a detailed discussion of the specific roles
RDFIs, and performs the settlement functions for and responsibilities of Third-Party Service
the financial institutions. In some cases, there are Providers, refer to Chapter 50 within these
two ACH Operators involved in a transaction, one Guidelines.
operating as the Originating ACH Operator and
the other as the Receiving ACH Operator. ACH TRANSACTION FLOW
In ACH terminology, Originator and Receiver
For a complete description of an ACH Operator, refer to the participants that initiate and receive
refer to Section IV of these Guidelines. the ACH entries. Unlike a check, which is always
a debit instrument, an ACH entry may be either
Receiving Depository Financial Institution a credit or a debit transaction. By examining
The Receiving Depository Financial Institution what happens to the Receiver’s account, one can
(RDFI) is the Depository Financial Institution distinguish the difference between an ACH credit
that receives ACH entries from the ACH Operator and an ACH debit transaction. If the Receiver’s
and posts them to the accounts of its depositors account is debited (balance decreased), then the
(Receivers). entry is an ACH debit. If the Receiver’s account
is credited (balance increased), then the entry is
Section III of these Guidelines addresses RDFIs an ACH credit. Conversely, the offset to an ACH
in detail. debit is a credit to the Originator’s account and the
offset to an ACH credit is a debit to the Originator’s
Receiver account.
A Receiver is a consumer or an organization that
has authorized an Originator to initiate an ACH ACH Credits
entry to the Receiver’s account with the RDFI. ACH credit entries occur when an Originator
initiates a transfer to move funds into a Receiver’s

OG2 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

account. For example, when a corporate buyer The example in Figure 1-2 illustrates the ACH
originates a payment for goods through the ODFI, credit process.
the ODFI initiates the credit transaction to transfer
the money into the corporate seller’s account at the Information and Funds Flow
RDFI. In this instance, the seller is the Receiver. Example:

ACH credit transactions involve both consumer As illustrated in Figure 1-2, a payroll deposit (PPD)
and corporate payments with distinct rules and credit flows from an account at a company’s financial
regulations for each. The most typical consumer institution to an account at an employee’s financial
ACH application is Direct Deposit of payroll. institution. Figure 1-2 also illustrates the flow of
a corporate trade exchange (CTX) credit from an
Some of the more common credits processed account at a company’s financial institution to an
through the ACH Network are listed below: account at a vendor’s financial institution. Credit
entries must be posted to a Receiver’s account no
• annuities later than Settlement Date. Consumer (PPD) credit
• customer-initiated transactions entries that are made available to the RDFI by its
(e.g., telephone bill payments) ACH Operator by 5:00 p.m. (RDFI’s local time) on
• corporate-to-corporate payments the banking day prior to Settlement Date must
be made available by opening of business on the
• dividends Settlement Date.
• interest payments
• payrolls – private and government ACH Debits
• pensions – private and government In an ACH debit transaction, funds flow in
the opposite direction. Funds are collected
• Social Security payments from a Receiver’s account and transferred to an
• tax payments Originator’s account, even though the Originator
• government vendor payments initiated the entry. For example, the Originator of

FIGURE 1-2  ACH CREDIT TRANSACTION INFORMATION AND FUNDS FLOW

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG3
SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

a preauthorized debit is the company to which the • tax payments

amount is owed. Consumers authorize a company • charitable donations
to debit their accounts for their monthly bills, such a
mortgage payments or utilities. Once a month, the The example in Figure 1-3 illustrates the ACH debit
company initiates a file of ACH debits through its process.
ODFI to withdraw the money from the consumers’
accounts. The company is the Originator, and the Information and Funds Flow
consumers are the Receivers.
Example:
Below are some of the more common debit
In Figure 1-3, a preauthorized mortgage payment
applications processed through the ACH Network
flows from a consumer’s account at a financial
today:
institution to a mortgage company’s account. Figure
1-3 also illustrates a corporate cash concentration
• association/club dues
flow from a company’s local or regional financial
• cash concentration institution account to a company’s regional or
• corporate-to-corporate payments national financial institution account. Debit entries
• contributions to Individual Retirement Accounts, must not be posted to a Receiver’s account prior to
SEPs, 401Ks, etc. the Settlement Date.

• government savings bonds purchases A typical transaction as it flows through the ACH
• holiday or vacation club payments Network might follow the path described below:
• insurance payments
• The Originating Depository Financial Institution
• mortgage and installment loan payments (ODFI) and the originating company determine,
• point of sale purchases by agreement, how the information must be
delivered to the ODFI. In some cases, the
• utility payments
Originator formats the data in accordance with

FIGURE 1-3  ACH DEBIT TRANSACTION

OG4 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

the requirements of the NACHA Operating The following are the three main participants (ODFI,
Rules and transmits it the ODFI. In other ACH Operator, RDFI) and their responsibilities
instances, the ODFI may take unformatted data concerning settlement and posting.
as a service to their client companies and does
the formatting itself. The ODFI establishes ODFI
processing schedules and cutoff times with its Settlement with the ODFI for entries originated
Originators so that entries may be processed usually occurs using the same procedures used for
and transmitted in sufficient time for settlement settlement of entries received. If the scheduled
to occur on the dates desired by its Originators. Settlement Date of a credit entry is not a banking
day for the ODFI, but the applicable Federal
• The company delivers the file to its ODFI. The Reserve office is open on that date, settlement will
timing of delivery must conform to appropriate occur on the scheduled Settlement Date.
schedules in order for the payment to settle on
the intended date. Specific procedures and timing of settlement
between the ODFI and the Originator are solely at
• The ODFI generally removes “on-us” entries the discretion of the ODFI and the Originator and,
and transmits the remaining entries to the ACH therefore, governed by agreement between them.
Operator by the ACH Operator’s processing
deadline. An “on-us” transaction is one in ACH Operator
which the Receiver and the Originator both
An ACH Operator calculates settlement totals owed
have accounts at the same financial institution.
to and by Participating DFIs based on the effective
Therefore, the transaction need not be transmitted
entry dates and processing dates contained within
through the ACH Network but instead may
batches of transactions. An ACH Operators provides
simply be retained by the financial institution
information to participants on the dollar amounts
and posted to the appropriate account.
that will be settled for each institution on each
Settlement Date. ACH entries processed by the
• The ACH Operator sorts the entries by RDFI
Federal Reserve ACH Operator are settled against
routing number and transmits the payment
the Participating DFI’s settlement account held at
information to the appropriate RDFI(s) for
the Federal Reserve. Settlement for transactions
posting.
processed by private sector ACH Operators is
determined by an arrangement with the Federal
On Settlement Date, all the ODFI, RDFI and ACH
Reserve.
Operator effect the appropriate settlement of
funds.
RDFI
Settlement While settlement between the Originator and
the ODFI is governed by agreement, settlement
Settlement is the actual transfer of the value of
between the RDFI and the Receiver is determined
funds between financial institutions to complete
by the NACHA Operating Rules, Federal Reserve
the payment instruction of an ACH entry.
availability schedules, and agreement.
The Federal Reserve provides settlement services
When an ACH file is processed by the receiving
for ACH entries processed by the Federal Reserve
ACH Operator, the ACH Operator will read the
and for private sector ACH Operators that process
effective entry date in the Company/Batch Header
ACH entries. The Federal Reserve ACH Operator
Record and settle according to that date. If the file
calculates the net credit and debit positions of
has been delivered to the ACH Operator so that the
financial institutions and applies those credits
ACH Operator is able to settle on the effective entry
or debits to the reserve accounts of the financial
date, it will insert the corresponding Julian Date in
institutions (or their correspondent banks) that are
the Settlement Date field. If the ACH Operator
maintained on the books of the Federal Reserve.
cannot settle on the effective entry date due to a

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG5
SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

stale date, weekend, or holiday, the ACH Operator • ACH credits will be delivered to an RDFI
will insert the Julian Date of the next business no earlier than two banking days prior to
day into the Settlement Date field reflecting that the Settlement Date. It is recommended that
settlement will occur on that date. credits be posted on the Settlement Date; credit
entries may, however, be posted prior to the
• Settlement information is produced by the ACH Settlement Date if the RDFI cannot warehouse
Operator as ACH entries are processed. This the entries. NACHA Operating Rules require that
information is accumulated based on the type credit entries must be available for withdrawal
of entry (debit or credit) by Settlement Date. by the customer no later than the Settlement
These settlement totals are reported to the RDFI Date of the entry. Further, according to NACHA
or its settlement member correspondent. Operating Rules, each PPD credit entry that is
made available to an RDFI by its ACH Operator
• The ACH Operator may provide ACH settlement by 5:00 p.m. (RDFI’s local time) on the banking
information in a machine-readable format to day prior to the Settlement Date must be made
facilitate the automation of settlement accounting available to the Receiver for withdrawal at the
for correspondent RDFIs. opening of business on the Settlement Date. For
this purpose, opening of business is defined as
• RDFIs should balance settlement totals daily the later of 9:00 a.m. (RDFI’s local time) or the
against totals posted to the RDFI’s customer time the RDFI’s teller facilities (including ATMs)
accounts and against any rejects that may occur are available for customer account withdrawals.
on a daily basis. Rejects and other differences
must be resolved immediately. CONSUMER VS. CORPORATE
PAYMENTS
• ACH settlement procedures are the same for
consumer and corporate transactions. In view ACH transactions are typically categorized
of the large-dollar entries that flow through the as either consumer payments or corporate
ACH Network for corporate customers, RDFIs payments, depending on the relationship of the
should have internal procedures in place to parties involved in the transaction and the type
monitor large-dollar settlement totals. of Receiver account. (Note: The term “corporate
payments” refers generally to any transaction to a
non-consumer account and includes corporations,
Posting
small businesses and non-profit organizations
The RDFI is responsible for posting entries and
alike.) In addition, payments are distinguished
for providing funds availability, both of which are
as Federal Government payments (including
determined by the Settlement Date in the Company
automated disbursements originating from the
Batch Header Record.
United States Government, such as Social Security
benefits, military and civilian payrolls, retirement
• ACH debits will be delivered to an RDFI no earlier
benefits, tax refunds, and disbursements for
than one banking day prior to the Settlement
state and federal revenue sharing programs) or
Date. NACHA Operating Rules state that debits
commercial payments (initiated by both individual
cannot be posted prior to the Settlement Date.
consumers and corporations).

If an RDFI is closed for business on the
Consumer payments currently made via the ACH
scheduled Settlement Date of a debit entry, but
Network include credit applications such as
the Receiving ACH Operator is open, the RDFI
payroll, retirement, dividend, interest, and annuity
will be debited on the scheduled Settlement
payments, in addition to educational benefit
Date unless it has advised the ACH Operator
reimbursements, payments and advances, and many
to delay settlement to the next business day of
others. Consumer ACH debit applications include,
the RDFI. If the ACH Operator agrees to delay
among others, the collection of insurance premiums,
settlement, the RDFI must pay for any costs of
mortgage and rent payments, utility payments,
float resulting from the deferral of settlement.
installment payments, a variety of membership
dues, and other recurring obligations.

OG6 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

Corporate ACH applications include cash MTE – Machine Transfer Entry

concentration and disbursement, corporate trade The ACH Network supports the clearing of
payments, state and Federal tax payments and transactions from Automated Teller Machines, i.e.,
financial electronic data interchange (EDI). Cash Machine Transfer Entries (MTE).
concentration and disbursement allows companies
to achieve efficiencies in cash management PPD – Prearranged Payment and Deposit Entry
through timely intra-company transfer of funds.
Direct Deposit
Corporate trade payments enable corporations
to exchange both data and funds with trading Direct deposit is a credit application that transfers
partners, facilitating an automated process of funds into a consumer’s account at the Receiving
updating their accounts receivable and accounts Depository Financial Institution. The funds being
payable systems. deposited can represent a variety of products, such
as payroll, interest, pension, dividends, etc.
PAYMENT APPLICATIONS
Direct Payment
The ACH Network supports a number of different Direct payment is a debit application. Through
payment applications. Unlike the wire transfer a written authorization, the consumer grants the
and check systems, the ACH is both a credit and company authority to initiate a debit – either one-
a debit payment system. An Originator initiating time or recurring - to his or her account.
entries into the ACH Network codes the entries
to indicate the type of payment, such as a debit
POS/SHR – Point of Sale Entry/
or credit to a consumer or corporate account. In Shared Network Transaction
certain cases, a particular application may be used
These two Standard Entry Class Codes represent
for both consumer and corporate transactions.
point of sale debit applications that occur in either
Each ACH application is identified and recognized
a shared (SHR) or non-shared (POS) environment.
by a specific Standard Entry Class Code, which
These transactions are most often initiated by the
appears in the ACH record format. The Standard
consumer via a plastic access card.
Entry Class Code also identifies the computer
record format that carries the payment and
payment related information for the application. RCK – Re-presented Check Entry
ACH entries may be transmitted to a variety of Originators can use this Single-Entry debit
account types. Both credit and debit entries may be transaction to re-present a check that has been
transmitted to demand accounts, savings accounts, processed through the check collection system
and financial institutions’ general ledger accounts. and returned because of insufficient or uncollected
Only credit entries (with the exception of reversals funds. Using the ACH Network, compared to the
to correct erroneous credit transactions) may be check collection process, provides Originators with
transmitted to loan accounts. A list of Standard the potential to control the timing of the initiation
Entry Class Codes and the different products each of the debit entry and to decrease costs.
code supports appears below.
TEL – Telephone-Initiated Entry
Consumer Applications This Standard Entry Class Code is used to originate
a debit entry to a consumer’s account based on
CIE – Customer Initiated Entry an oral authorization obtained from the consumer
Customer Initiated Entries are credit applications via the telephone. This type of transaction may
used when the consumer initiates the transfer of only be originated when (1) there is an existing
funds, typically to a company for payment of funds relationship between the Originator and the
owed to that company. CIE entries are usually Receiver, or (2) where no relationship exists
initiated through some type of home banking between the Originator and the Receiver, but the
product or bill payment service provider. Receiver has initiated the telephone call.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG7
SECTION I – General Information
CHAPTER 1  OVERVIEW OF THE SYSTEM

WEB – Internet-Initiated/Mobile Entry entry is obtained through notice provided to the

This Standard Entry Class Code is used to originate Receiver by the payee and the Receiver’s going
debit entries to a consumer’s account based on an forward with the transaction.
authorization that is communicated, other than by
an oral communication, from the Receiver to the BOC – Back Office Conversion Entry
Originator via the Internet or a Wireless Network. This Standard Entry Class Code enables Originators
This Standard Entry Class Code also includes debit to convert, during back office processing, an eligible
entries authorized under any form of authorization check received at the point of purchase or manned
when the instruction for the initiation of the entry bill payment location to a Single-Entry ACH debit.
is provided to the Originator, other than by an oral The Receiver’s source document (i.e., the check)
communication, over a Wireless Network. WEB is used to collect the Receiver’s routing number,
entries can be either single or recurring entries. account number, check serial number, and dollar
The WEB SEC Code helps to address unique amount for the transaction. Authorization for a
risk issues inherent to the Internet and wireless BOC entry is obtained through notice provided by
payment environments through requirements for the Originator at the point of purchase or manned
added security procedures and obligations. bill payment location and the Receiver’s going
forward with the transaction.
Corporate Applications
CCD – Corporate Credit or Debit IAT – International ACH Transaction
This application can be either a credit or debit This Standard Entry Class Code identifies an ACH
application where funds are transferred between credit or debit entry that is part of a payment
unrelated corporate entities, or transmitted as intra- transaction that involves a financial agency’s office
company cash concentration and disbursement that is not located within the territorial jurisdiction
transactions. This application can serve as a stand- of the United States. These international payments
alone funds transfer, or it can support a limited convey specific information defined within the
amount of payment related data with the funds Bank Secrecy Act’s “Travel Rule” to ensure that
transfer. all parties to the transaction have the information
necessary to comply with U.S. law, which includes
CTX – Corporate Trade Exchange the programs administered by the Office of Foreign
Assets Control (OFAC).
The Corporate Trade Exchange application
supports the transfer of funds (debit or credit) in
a trading partner relationship in which a full ANSI
POP – Point-of-Purchase Entry
ASC X12 message or payment related UN/EDIFACT This ACH debit application is used as payment for
information is sent with the funds transfer. The the in-person purchase of goods or services. The
ANSI ASC X12 message or payment related UN/ Originator can initiate a single-entry debit based
EDIFACT information is placed in multiple addenda on a written authorization from the Receiver and
records. notice provided by the Originator at the point of
purchase or manned bill payment location. The
Applications Permitted to Both Consumer source document, which is voided by the merchant
and Non‑Consumer Accounts and returned to the Receiver at the point-of-
purchase, is used to collect the Receiver’s routing
ARC – Accounts Receivable Entry
number, account number, and check serial number
This Standard Entry Class Code enables Originators to generate the debit entry to the Receiver’s
to convert an eligible check received via the U.S. account.
mail or delivery service, at a dropbox location, or in
person for payment of a bill at a manned location Other Applications
to a Single-Entry ACH debit. The Originator uses
the Receiver’s source document (i.e., the check) ACK/ATX – Acknowledgment Entries
to collect the Receiver’s routing number, account These optional Standard Entry Class Codes can be
number, check serial number, and dollar amount used by the RDFI to acknowledge the receipt of
for the transaction. Authorization for an ARC ACH credit payments originated using the CCD or

OG8 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 2  LEGAL FRAMEWORK

CTX formats. These acknowledgments indicate to cannot be made, and (3) check images that are
the Originator that the payment was received and unprocessable.
that the RDFI will attempt to post the payment to
the Receiver’s account. Acknowledgment entries
initiated in response to a CCD credit entry utilize
the ACK format. Acknowledgments initiated CHAPTER 2
in response to a CTX credit entry utilize the
ATX format. Legal Framework

ADV – Automated Accounting Advice

The ACH process operates from beginning to end
This Standard Entry Class Code represents an
through a series of legal agreements. Every ODFI
optional service to be provided by ACH Operators
and RDFI that transmits entries through the ACH
that identifies advices of ACH accounting
Network must have an agreement with an ACH
information in machine readable format for
Operator that binds it to the NACHA Operating
Participating DFIs.
Rules. Before any transaction is initiated, the
Originator and ODFI execute an agreement to
COR – Notification of Change or
use the ACH Network to originate payments. The
Refused Notification of Change
agreement must bind the originating company to
This Standard Entry Class Code is used by an RDFI the NACHA Operating Rules, identify restrictions on
or ODFI when originating a Notification of Change the type of ACH transactions that can be originated,
or Refused Notification of Change. and address the ODFI’s right to terminate or
suspend the agreement for a breach of the Rules.
DNE – Death Notification Entry In addition, the agreement should define the
Federal Government agencies (e.g., Social Security parameters of the relationship between the two
Administration) can use this application to notify parties, identify processing requirements for the
a depository financial institution that the recipient specific application(s), and establish liability and
of a government benefit payment has died. accountability for procedures related to certain
application(s). In some cases, agreements exist
ENR – Automated Enrollment Entry between the RDFI and the Receiver, particularly
This SEC Code allows a depository financial if the Receiver is a non-consumer or government
institution to transmit ACH enrollment information entity.
to Federal Government agencies via the ACH
Network for future credit and debit applications While the NACHA Operating Rules is the primary
on behalf of both consumers and companies. document addressing the rules and regulations for
the commercial ACH Network, Federal Government
TRC/TRX – Truncated Entries ACH payments are controlled by the provisions of
Title 31 Code of Federal Regulations Part 210 (31
This Standard Entry Class Code identifies batches
C.F.R. Part 210). The Financial Management Service
of truncated checks.
(FMS) of the U.S. Department of the Treasury is
For more information on check truncation, the agency responsible for establishing Federal
please see the Operating Rules of the National Government ACH policy. In 1999, 31 C.F.R. Part
Association for Check Safekeeping, available 210 was revised by FMS to adopt the provisions
for purchase from NACHA. of the NACHA Operating Rules as the regulations
governing the transmission and receipt of Federal
Government ACH entries, with certain exemptions
XCK – Destroyed Check Entry
to address matters of Federal law. FMS also
This application can be utilized by a collecting publishes The Green Book, a procedural manual
institution for the collection of (1) certain checks for Federal Government ACH payments.
that have been destroyed or lost, (2) checks that
have been damaged such that processable images

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG9
SECTION I – General Information
CHAPTER 2  LEGAL FRAMEWORK

Other laws that have a direct bearing on ACH Additional information on Reg D is available
operations are the Uniform Commercial Code on the Federal Reserve’s website at http://www.
Article 4 (which governs check transactions) and federalreserve.gov/bankinforeg/reglisting.
Article 4A(which governs funds transfers), and htm.
the Electronic Funds Transfer Act as implemented
by Regulation E. Certain other activities related REGULATION E
to ACH payments are affected by The Right to
Regulation E implements the Electronic Fund
Financial Privacy Act, Regulation D regarding
Transfer Act (EFTA). The regulation establishes
reserve requirements, Regulation CC regarding
basic rights and responsibilities of consumers
funds availability, and other regulatory agency
and financial institutions that use electronic funds
directives. Relationships between the consumer as
transfer services. Regulation E (Reg E) applies to
Receiver and the RDFI are generally governed by
consumer transactions only and provides a series
Regulation E and the account agreement.
of protections to consumer users of electronic
funds transfers.
REGULATION D
The Federal Reserve Board’s Regulation D imposes Topics covered in Reg E include similarly
reserve requirements on certain deposits held by authenticated written authorizations; authorization
depository institutions, including all FDIC-insured requirements for merchants and other payees
banks, insured credit unions, savings banks, and that initiate electronic check transactions; pre-
mutual savings banks. Depository institutions authorized electronic funds transfers; notice
must maintain reserves in the form of cash in their obligations for Originators; initial and periodic
vaults or, if vault cash is insufficient, as a balance disclosures; error resolution; and other issues.
in an account at a Federal Reserve Bank or with a The Official Staff Interpretations of Reg E provide
pass-through correspondent. Reserve requirements guidance on the regulation’s coverage of electronic
are currently between three and ten percent of a check conversion transactions, computer-initiated
depository institution’s net “transaction accounts.” bill payments, as well as authorization of recurring
debits from a consumer’s account, among other
A “transaction account” is an account from which matters.
the depositor may make transfers or withdrawals by
check, debit card, or other electronic instruction. If Reg E applies to any electronic fund transfer that
an account does not permit the depositor to make authorizes a financial institution to debit or credit
more than six such transfers or withdrawals per a consumer’s account, with certain exceptions.
month, the institution may classify the account as Electronic fund transfer means any transfer of funds
a “savings deposit” and not a transaction account. that is initiated through an electronic terminal,
Savings deposits are not subject to the reserve telephone, computer, or magnetic tape for the
requirement. purpose of ordering, instructing, or authorizing a
financial institution to debit or credit a consumer’s
If the financial institution permits more than the account.
authorized number of transfers or withdrawals per
month from an account, that account is a transaction The term “electronic fund transfer” includes, but is
account even if the institution calls it a savings not limited to:
deposit or “savings account,” and is thus subject
to transaction account reserve requirements. If a – POS transfers
depository institution gives a customer access to – ATM transfers
savings accounts via the ACH Network or another
– Direct deposits or withdrawals of funds
electronic payments mechanism, the account
generally must be classified as a transaction – Telephone transfers
account, unless the specified kinds of withdrawals – Debit card transactions
and transfers are limited in number each month
to not more than six per month (including Reg E coverage also extends to situations in which
ACH debit). a check, draft, or similar paper instrument is used

OG10 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 2  LEGAL FRAMEWORK

as a source of information to initiate a one-time UCC 4A

electronic fund transfer from a consumer’s account.
Article 4A of the Uniform Commercial Code (UCC)
A check enables the merchant or other payee to
applies to payment orders addressed to a bank to
capture the routing, account and serial numbers to
pay money to a beneficiary. It is a comprehensive
initiate the transfer.
body of state law that governs wholesale EFT credit
transactions, including those transmitted over
Reg E does not govern:
CHIPS, Fedwire, the ACH Network, and as on-us
entries. Wholesale credit transfers are payments
– Electronic debits or credits to non-consumer
that are transmitted through the banking system
accounts
by financial institutions and commercial entities
to non-consumer accounts. Check or other debit
– Checks
transfers, including ACH debit transactions, are not
covered under Article 4A.
– Check guarantee or authorization services
Consumer electronic funds transfers subject to
– Any transfer of funds through Fedwire or
Regulation E, including ACH credit transactions,
through a similar wire transfer system that is
are not subject to UCC 4A. However, there is one
used primarily for transfers between financial
exception to this coverage. Since preauthorized
institutions or between businesses
consumer credits to financial institutions with an
– The purchase or sale of securities or commodities asset size of $100 million or less are not covered
(1) regulated by the Securities and Exchange by Reg E, consumer ACH credits that fall in this
Commission (SEC) or the Commodities Futures category are also not covered by Reg E. Instead,
Trading Commission (CFTC); (2) purchased or these consumer ACH credit transactions are subject
sold through a broker-dealer regulated by the to UCC 4A.
SEC or CFTC, or (3) held in book entry form by a
Article 4A provides for a “choice of law” to
Federal Reserve Bank or federal agency.
determine which state’s substantive law will be
– Automatic transfers under agreement between applied to the various parties of an electronic
a consumer and financial institution, which credit. The NACHA Operating Rules specify that,
provides that the institution will initiate individual unless there are agreements that state otherwise,
transfers without a specific request from the ACH transactions are governed by the version of
consumer, including interest and loan payments, UCC 4A adopted by the state of New York.
transfers from checking to savings and vice versa,
UCC 4A is structured to provide incentives for the
and transfers between family members’ accounts
Originator, ODFI or RDFI involved in a transaction
held in the same financial institution.
that is in the best position to avoid loss to do
– Telephone-initiated transfers between a consumer so. The article imposes interest penalties on the
and a financial institution that do not take offending party for delayed transfers.
place under a telephone bill payment or other
Although some provisions of Article 4A may be
prearranged plan or agreement
altered by the agreement between the ODFI and
– Preauthorized debits or credits to financial Originator or between the RDFI and Receiver,
institutions whose asset size is $100 million some cannot. Those provisions that can be altered
or less may be overruled by the NACHA Operating Rules.
However, the Rules do not address issues or
Additional information about Reg E can be disputes between financial institutions and their
found on the Federal Reserve’s website. Visit customers.
http://www.federalreserve.gov/bankinforeg/
reglisting.htm for the latest, detailed
information on Reg E.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG11
SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

More information on UCC 4A can be found domestic or international. This Chapter is divided
in the NACHA publication, Revised Uniform into two sections: Domestic ACH OFAC Obligations
Commercial Code Article 4A and the Automated and International ACH OFAC Obligations.
Clearing House Network.
DOMESTIC ACH OBLIGATIONS
In September 1997, the NACHA Operating Rules
were amended to require that Originator/ODFI
CHAPTER 3 agreements include an acknowledgment by the
OFAC Requirements and Originator that ACH transactions it originates
comply with the laws of the United States (“NACHA
Obligations Rule”). The effect of this rule change is to focus
financial institution liability for inadvertent
processing of a domestic ACH transaction in
The U.S. Treasury Department’s Office of Foreign violation of OFAC-enforced sanctions policies on
Assets Control (OFAC) administers economic the financial institution holding the account of the
sanctions and embargo programs that require blocked party.
assets and transactions involving interests of target
countries, target country nationals, and other
IMPACT TO ACH NETWORK
specifically identified companies and individuals
be frozen. For purposes of OFAC compliance, these
PARTICIPANTS FOR DOMESTIC
entities are referred to as “Specially Designated
ACH TRANSACTIONS
Nationals and Blocked Persons.” OFAC maintains Originators
and regularly updates a master list (SDN List) Domestic Originators should be aware that they
identifying known “blocked parties.” are subject to applicable U.S. law, including OFAC-
enforced sanctions, when initiating ACH entries.
All of the sanctions programs enforced by OFAC Foreign Originators initiating transactions with a
involve declarations of national emergency by financial institution that is under U.S. jurisdiction
the President of the United States. As with all similarly must be aware that the institution is
payment mechanisms, the ACH Network is subject subject to OFAC-enforced sanctions. Originators in
to the requirement to comply with OFAC-enforced either category should not be acting on behalf of,
sanctions policies. or transmitting funds to or from, any blocked party
subject to OFAC-enforced sanctions. Agreements
Who is subject to OFAC? All U.S. citizens and between ODFIs and Originators should include a
permanent resident aliens, companies located in statement that the Originator acknowledges that
the U.S., overseas branches of U.S. companies, it may not initiate ACH entries that violate the
and, in some cases, overseas subsidiaries of U.S. laws of the United States. Originators should
companies fall under OFAC jurisdiction. In terms be aware that they will be held to an obligation
of the ACH Network, this means that all U.S. ACH to originate only lawful ACH transactions under
participants, including Originators, Originating such agreements with their ODFIs. Originators of
Depository Financial Institutions (ODFIs), ACH transactions should also be aware that their
Receiving Depository Financial Institutions ODFI may from time to time need to temporarily
(RDFIs), Receivers and third-parties need to suspend processing of a transaction (particularly an
be aware that they can be held accountable for International ACH Transaction) for greater scrutiny
sanctions violations by the U.S. Government and or verification against the SDN List, and that this
must understand their compliance obligations. action may affect settlement and/or availability.

SCOPE OF COVERAGE ODFIs

OFAC responsibilities for a financial institution vary ODFIs that choose to originate ACH entries on
depending on whether the transaction is considered behalf of their customers should be aware that

OG12 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

both they and their Originators are subject to the Entries Violating OFAC Sanctions
NACHA Operating Rules and applicable U.S. law Each ODFI should be aware that if it inadvertently
when transmitting these entries. ODFIs should transmits an unlawful ACH credit entry to a
make this obligation clear in their agreements Receiver that is subject to OFAC sanctions, the RDFI
with Originators. ODFIs processing International holding the blocked party’s account is obligated
ACH Transactions may also find it beneficial to to post the credit entry to the Receiver’s account,
include in their agreements a reference to possible freeze the proceeds, and report the transaction
delays in processing, settlement and/or availability to OFAC.
of these transactions when the ODFI determines
that enhanced scrutiny or verification may be In the event that the ODFI inadvertently processes
necessary. an unlawful ACH debit entry to a blocked
account, the RDFI holding the blocked account
The NACHA Operating Rules reflects the “Know (or an intermediary receiving point such as a
Your Customer” principle that the ODFI will verify correspondent or third-party processor able to
the Originator is not a blocked party and that a identify the transaction), in compliance with OFAC
good faith effort will be undertaken to determine, policies, should return the entry in accordance
through the normal course of business, that the with the NACHA Operating Rules using Return
Originator is not engaged in transmitting funds to, Reason Code R16 (Account Frozen). In this way,
from, or on behalf of a party subject to a blocking the proceeds do not leave the blocked account and
action. If the ODFI encounters a transaction in the ODFI is informed of the reason.
the normal course of business initiated by an
Originator that would violate OFAC-enforced If the ODFI is instructed to originate an ACH debit
sanctions, federal law requires the ODFI to comply entry that it has reason to believe would be an
with OFAC policies. Under U.S. law, the ODFI is unlawful transaction, NACHA has been advised
responsible for freezing or rejecting the proceeds that OFAC would prefer that the transaction be
of illicit ACH transactions involving interests of transmitted so that, if not returned or rejected by
blocked parties for whom the ODFI holds an the RDFI, the proceeds from the transaction can
account. As a depository financial institution, the be captured by the ODFI, frozen and reported
ODFI should have a process in place to determine to OFAC. See section on “Handling IAT Debit
whether any of its account holders is identified as Processing” for more information.
a blocked party in a current SDN List (see section
on “Account Screening” below). Identification of Blocked Parties
As blocked parties and related transactions may
Origination of Entries be difficult to identify in the normal course of
With respect to domestic ACH transactions, by business, ODFIs may wish to become familiar
addressing the issues above, the ODFI may rely with how to locate and interpret lists of specially-
on the RDFI for compliance with OFAC policies designated nationals and blocked persons subject
when it is the RDFI that holds the account or is to U.S. sanctions to facilitate OFAC compliance
otherwise acting on behalf of a blocked person. and avoid liability for monetary penalties.
Consultation with counsel, audit/compliance staff,
As noted above, the ODFI should address the and/or wire transfer operations personnel — in
Originator’s obligation to comply with U.S. laws addition to visiting and becoming familiar with
in its origination agreement. The ODFI should the OFAC website at http://www.treas.gov/ofac —
also recognize that when unbundling “on us” is recommended. There are also several vendors
transactions (i.e., the ODFI is also the RDFI for of online or database SDN identification services
a transaction) from files received for processing that can assist financial institution reviews at the
from an Originator, it will need to review these account level, including the new account set-up
transactions with greater scrutiny since it is phase or reviewing existing accounts when new
servicing both sending and receiving sides. blocked parties are added to the SDN List.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG13
SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

RDFIs Receivers
RDFIs should be aware that they are subject to Domestic Receivers (and those otherwise under
the requirements of the NACHA Operating Rules U.S. jurisdiction) are subject to U.S. law, including
and applicable U.S. law when processing ACH OFAC sanctions, and should be aware that their
entries. This includes the need to comply with financial institutions are subject to both U.S. law
OFAC enforcement policies in the event that the and the NACHA Operating Rules when handling
RDFI receives an ACH transaction being made to, ACH transactions on their behalf. This may involve
from, or on behalf of any party subject to OFAC delays in posting, settlement and the availability
sanctions. As a depository financial institution, the of proceeds — particularly for ACH transactions
RDFI should have a process in place to determine initiated by parties outside U.S. jurisdiction — if an
whether any of their account holders is identified RDFI finds it necessary to scrutinize a transaction
as a blocked party in a current SDN List (see in more detail. In the case where there appears to
section on “Account Screening” below). be a violation of U.S. sanctions policies, proceeds
from an ACH credit may be frozen and therefore
Receipt of Entries unavailable to the Receiver pursuant to a blocking
With respect to domestic ACH transactions, the action. For unlawful ACH debits, Receivers may
RDFI is responsible for rejecting or freezing the have the proceeds debited from their account and
proceeds of a transaction involving interests of a frozen by either the RDFI or the ODFI pursuant to
blocked party for whom the RDFI holds an account a blocking action.
or on whose behalf the RDFI is acting.
Third-Parties
Entries Violating OFAC Sanctions Third-parties (including processors and
In the event that an ODFI inadvertently transmits correspondent/respondent banks) should recognize
an unlawful ACH credit entry to a Receiver that is that OFAC sanctions enforcement applies to their
subject to OFAC sanctions, the RDFI holding the role as it would the party they are acting on behalf
blocked party’s account should post the credit entry of. For example, a third-party acting on behalf
to the account, ensure the account is frozen, and of a number of downstream corporate Originators
report the transaction to OFAC. In the event that should recognize that its ODFI will hold it
an ODFI inadvertently transmits an unlawful ACH accountable for ensuring that ACH transactions it
debit entry, the RDFI holding the account should introduces into the domestic ACH Network comply
ensure the account is frozen, report the transaction with U.S. law. This means that the ODFI has to rely
to OFAC, and return the entry in accordance with on the third party to police downstream parties for
the NACHA Operating Rules using Return Reason which it is acting.
Code R16 (Account Frozen) with advice that the
entry was destined to an account frozen due to Similarly, a domestic respondent bank/RDFI
OFAC blocking action. receiving ACH transactions through a correspondent
bank should not automatically assume that its
Identification of Blocked Parties correspondent will have intercepted and frozen
any unlawful transactions it has processed on the
As blocked parties and related transactions may be
respondent’s behalf. While there may be some
difficult to identify in the normal course of business,
attention focused on the correspondent in the event
RDFIs may wish to become familiar with how to
of an unlawful transaction being passed through,
locate and interpret lists of specially-designated
the correspondent serving the RDFI is generally
nationals and blocked persons subject to U.S.
not in a position to verify the identity of the RDFI’s
sanctions to ensure compliance and avoid liability
accountholder (or the ODFI’s Originator) on a
for sizeable monetary penalties. Consultation
particular ACH transaction.
with counsel, audit/compliance staff, and/or wire
transfer operations personnel is recommended.

OG14 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

INTERNATIONAL ACH OFAC International Emergency Economic

OBLIGATIONS Powers Act
Financial institution OFAC compliance policies
50 U.S.C. § 1702(a)(3)  Presidential
should include the processing of IAT transactions.
authorities
In a letter from OFAC to NACHA dated November
9, 2004, OFAC outlined their expectations for both
Compliance with any regulation,
the ODFI and RDFI. “U.S. RDFIs and beneficiaries
instruction, or direction issued under
will continue to have an obligation to ensure that all
this chapter shall to the extent thereof
aspects of inbound, cross-border transactions are
be a full acquaintance and discharge for
in compliance with OFAC regulations and to take
all purposes of the obligations of the
appropriate steps to investigate, suspend, reject,
person making the same.  No person
block and report on transactions as necessary.”
shall be held liable in any court for
“U.S. ODFIs and their Originators will continue
or with respect to anything done or
to be responsible for ensuring that all parties to
omitted in good faith in connection
the transactions, as well as the underlying purpose
with the administration of, or pursuant
of the transactions, are not in violation of OFAC
to and in reliance on, this chapter, or
regulations, and they will need to take appropriate
any regulation, instruction, or direction
steps to investigate, suspend, reject, block, and
issued under this chapter.
report on transactions.”
Trading with the Enemy Act
OFAC VS. REGULATION E,
REGULATION CC, AND THE 50 U.S.C. App. § 5(b)(2)
NACHA OPERATING RULES
When performing an OFAC review of a suspect Any payment, conveyance, transfer,
transaction, it may take some time to obtain assignment, or delivery of property
sufficient information on the parties to the or interest therein, made to or for the
transaction to clear the suspect item. NACHA has account of the United States, or as
modified the NACHA Operating Rules, Article One, otherwise directed, pursuant to this
Section 1.2, Subsection 1.2.1 Effect of Illegality to subdivision or any rule, regulation,
allow financial institutions the time necessary to instruction, or direction issued
clear a suspect transaction before it is processed. hereunder shall to the extent thereof
be a full acquaintance and discharge
For more information of the Effect of Illegality, for all purposes of the obligation of the
see Chapter 43 of these Guidelines. person making the same; and no person
shall be held liable in any court for or
Questions have been raised about the impact of in respect to anything done or omitted
Regulation E and Regulation CC on consumer in good faith in connection with the
transactions and OFAC requirements and which administration of, or in pursuance of
regulation takes precedence. and in reliance on, this subdivision,
or any rule, regulation, instruction, or
Most of the OFAC programs that fall under the direction issued hereunder.
International Emergency Economic Powers Act and
the Trading with the Enemy Act involve “declarations DEMONSTRATING COMPLIANCE
of national emergency” by the President and both For a financial institution to demonstrate OFAC
contain “hold harmless” provisions for complying compliance, it must have a clear and thorough
with sanctions law.  The following sections site the ACH OFAC policy and procedures manual (or
specific sections of the regulations. section on ACH OFAC policies and procedures
in its OFAC policy and procedures manual),
educate and train its employees on the new
policies, and have a compliance system or

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG15
SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

procedure that allow for the proper handling Financial Institution as a Gateway
of all transactions and customers. Some of the A financial institution acting as a Gateway may
items that should be covered in the ACH OFAC process Inbound and Outbound IAT credit and
policy are: debit transactions. The FI acting as a Gateway must
review the IAT transactions for OFAC compliance.
• Who is responsible for OFAC compliance; Although populating the Gateway Operator OFAC
Screening Indicator with the results of the scan
• How the organization maintains an up-to-date is optional, it is a good business practice. OFAC
listing of prohibited countries, organizations, has stated that the responsibility for investigating
and individuals (detail how the organization suspect IAT transactions may be passed to the
obtains the information from OFAC and when); RDFI, but within the NACHA Operating Rules,
the Gateway has taken on the warranties and
• How specific transactions are handled (i.e. responsibilities of the ODFI. As such, the Gateway
debits, credits); warrants that all transactions originated are in
compliance with U.S. law. To that end a financial
• What information is checked against the “SDN” institution acting as a Gateway should investigate
list; and clear any suspect IAT transactions before they
are originated into the ACH Network. If an IAT
• OFAC reporting procedures;
debit transaction is found to be in violation of an
OFAC sanctions policy, OFAC has stated that all
• Record retention; and
processing should cease; that the Gateway/ODFI
is to notify OFAC within 10 days. The Gateway
• OFAC compliance audit.
should notify the Foreign Gateway that the item
has been rejected or frozen because it was in
IMPACT TO ACH NETWORK violation of U.S. law, and the Gateway should send
PARTICIPANTS FOR INTERNATIONAL a copy of the unlawful transaction to the RDFI.
ACH TRANSACTIONS (IAT)
Gateways Originators
The Gateway is defined as either a financial Corporate Originators should be aware that they
institution or an ACH Operator that acts as the entry are subject to applicable U.S. law, including OFAC-
point to or exit point from the United States for enforced sanctions, when initiating ACH entries.
IAT entries. The capabilities and responsibilities Originators should not be acting on behalf of, or
vary between financial institution and transmitting funds to or from, any blocked party
ACH Operator. subject to OFAC-enforced sanctions. Agreements
between ODFIs and Originators should include a
ACH Operator Acting as a Gateway statement that the Originator acknowledges that
An ACH Operator acting as a Gateway may they may not initiate ACH entries that violate the
process Outbound IAT debit and credit entries but laws of the United States. Originators should
may only process Inbound IAT credit entries and be aware that they will be held to an obligation
reversing debits. No Inbound IAT debit entries to originate only lawful ACH transactions under
may be processed by an ACH Operator acting as such agreements with their ODFIs. Originators of
a Gateway. ACH transactions should also be aware that their
ODFI may, from time to time, need to temporarily
An ACH Operator acting as a Gateway must review suspend processing of an IAT transaction for
all IAT entries for OFAC compliance and populate greater scrutiny or verification against the SDN
the Gateway Operator OFAC Screening Indicator List, and that this action may affect settlement and/
(Field 10 of the IAT Entry Detail Record) with the or availability.
results of the review before passing the entry to
the RDFI. The ACH Operator is not required to
investigate any suspect transaction.

OG16 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

ODFIs from OFAC (GEN-594137) stating its position. In

ODFIs that choose to originate ACH entries on the letter, OFAC states:
behalf of their customers should be aware that
both they and their Originators are subject to the “It is OFAC’s position that a financial
NACHA Operating Rules and applicable U.S. law institution that performs its OFAC
when transmitting these entries. ODFIs should screening after having credited a
make this obligation clear in their agreements with beneficiary’s account increases its OFAC
Originators. risk substantially.

The ODFI is responsible for reviewing all IAT When a financial institution credits a
transactions for OFAC compliance prior to the beneficiary’s account with the proceeds
items being released to the ACH Operator. All of a transaction that is in violation of
parties to the transactions should be reviewed OFAC regulations, it has committed a
including the name and physical address of the violation by processing the transaction
Originator and Receiver, the receiving bank name, forward. The consequences of the
identification and branch country code, and any violation can be mitigated if the
remittance information in the Payment Related institution is able to prevent the
Information contained in the optional Remittance beneficiary’s access to the funds until
Information addenda record. If suspect transactions the OFAC screening is completed, or is
are identified during the review, the items should otherwise able to recover the funds prior
be investigated and cleared before the transactions to their being used by the beneficiary.”
are released to the ACH Operator. If the ODFI
encounters a transaction initiated by an Originator A copy of OFAC’s letter can be found on the
that would violate OFAC-encountered sanctions, IAT Resource page on the NACHA website at
Federal law requires the ODFI to comply with www.nacha.org
OFAC policies. Under U.S. law, the ODFI is
responsible for freezing or rejecting (depending on Handling Unlawful Transactions
the specifics of the particular sanctions program) Credit Entries:
the proceeds of illicit ACH transactions involving
interests of blocked parties. If the RDFI receives an inbound unlawful IAT
credit entry to a Receiver that is subject to
RDFIs OFAC sanctions, the RDFI holding the blocked
RDFIs should be aware that they are subject to the party’s account should post the credit entry to
requirements of the NACHA Operating Rules and the account, ensure the account is frozen, and
applicable U.S. law when processing ACH entries. report the transaction to OFAC.
This includes the need to comply with OFAC
enforcement policies in the event that the RDFI 
If the Originator of the IAT entry is subject
receives an ACH transaction being made to, from, to OFAC sanctions the transaction should not
or on behalf of any party subject to OFAC sanctions. be posted to the Receiver’s account, the funds
The RDFI is responsible for rejecting or freezing should be suspended and the transaction
the proceeds of a transaction involving interests of reported to OFAC.
blocked parties.
Debit Entries:
Timing of OFAC Screening of IAT Transactions
If the RDFI receives an unlawful IAT debit entry,
NACHA has received reports that some RDFIs do the RDFI should investigate the transaction
not screen IAT entries for OFAC compliance prior and, if it is found to be in violation of an OFAC
to posting them to the Receiver’s account. In some sanction, should contact OFAC for guidance.
cases, this is due to system or software constraints OFAC will handle these transactions on a case-
at the RDFI. NACHA contacted OFAC requesting by-case basis.
comment on this practice and received a letter

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG17
SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

There is no time limit for the resolution of the RECOMMENDED PROCEDURES

suspect transaction. The RDFI needs to ensure that FOR HANDLING INBOUND IAT DEBIT
it communicates with the ODFI on the resolution TRANSACTIONS
of the suspect transaction.
NACHA developed the following recommendations
and guidance for Gateways and RDFIs for
Receivers
processing inbound IAT debits in accordance with
Receivers are subject to U.S. law, including OFAC OFAC requirements.
sanctions, and should be aware that their financial
institutions are subject to both U.S. law and the Inbound IAT debit transactions are debits that are
NACHA Operating Rules when handling ACH being originated into the U.S. ACH Network by U.S.
transactions on their behalf. This may involve financial institutions acting as Gateways. Inbound
delays in posting, settlement and the availability IAT debit transactions will not be processed
of proceeds — particularly for ACH transactions through the FedACH International Service. While
initiated by parties outside U.S. jurisdiction — if an a Gateway is also, by definition, the ODFI for an
RDFI finds it necessary to scrutinize a transaction inbound IAT debit, the recommendations here are
in more detail. In the case where there appears to intended to address the financial institution’s role
be a violation of U.S. sanctions policies, proceeds as a Gateway. Nothing here should be construed
from an ACH credit may be frozen and therefore to apply to ODFIs for any transactions other than
unavailable to the Receiver due to a blocking inbound IAT debits.
action. For unlawful ACH debits, Receivers may
have the proceeds debited from their accounts and NACHA strongly encourages financial institutions
frozen by the RDFI pursuant to a blocking action. that are considering serving as Gateways to
thoroughly understand OFAC requirements,
Third-Parties transaction risks, and operational issues for
Third-parties (including processors and various processing scenarios. Financial institutions
correspondent/respondent banks) should recognize should have well‑thought‑out business plans and
that OFAC sanctions enforcement applies to their should thoroughly understand the implications
role as it would the party they are acting on behalf and responsibilities of processing IAT debit
of. For example, a third-party acting on behalf transactions.
of a number of downstream corporate Originators
should recognize that its ODFI will hold it The recommendations and guidance contained
accountable for ensuring that ACH transactions it within this section reflect the expectations of
introduces into the domestic ACH Network comply OFAC — they are not requirements of the NACHA
with U.S. law. This means that the ODFI has to rely Operating Rules. Financial institutions can always
on the third-party to police downstream parties for contact OFAC for guidance whenever appropriate.
which it is acting.
OFAC Requirements Related to Inbound
Similarly, a domestic respondent bank/RDFI IAT Debits
receiving ACH transactions through a correspondent Under OFAC’s requirements, a Gateway that
bank should not automatically assume that its identifies the presence of a blocked party in an
correspondent will have intercepted and frozen inbound IAT debit should cease processing the
any unlawful transactions it has processed on the entry, and should take several additional steps to
respondent’s behalf. While there may be some report the hit to OFAC, the Foreign Gateway, and
attention focused on the correspondent in the event the RDFI.
of an unlawful transaction being passed through,
the correspondent serving the RDFI is generally OFAC further expects that Gateways’ notifications
not in a position to verify the identity of the RDFI’s to RDFIs about OFAC hits will eventually take
account-holder (or the ODFI’s Originator) on a place through the ACH Network. NACHA will
particular ACH transaction. issue additional guidance when methods and
procedures for these notifications are established.

OG18 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

Gateway (ODFI) Responsibilities for Inbound Under these processing guidelines, there should
IAT Debit Transactions be no instances in which a Gateway transmits an
A financial institution acting as a Gateway (ODFI) inbound IAT debit in which there is a “1” in the
for Inbound IAT debits should: OFAC Screening Indicator. All suspect transactions
would either be cleared or processing would
• Review all Inbound IAT debits for OFAC cease.
compliance, including all parties to the
transaction and all remittance data; Gateway Procedures for Rebalancing a
Batch and File
• Segregate any suspect transactions into an OFAC ACH operations software should rebalance the
review module or queue; batch and file to include revisions to the following
fields: Total Debit Entry Dollar Amount in Batch/
• Populate the Gateway Operator OFAC Screening File, Total Credit Entry Dollar Amount in Batch/
Indicator (Field 10, IAT Entry Detail Record) for File, Entry/Addenda Count and Entry Hash at
clean transactions with “0.” (NOTE: This field both the Batch Control and File Control level and,
is Optional under the NACHA Operating Rules, possibly, the Batch Count and/or Block Count in
but its use is strongly encouraged); the File Control Record.

• Rebalance the original batch and file, if necessary, RDFI Responsibilities for Inbound IAT
and send to the ACH Operator (see section Debit Transactions
below on Gateway Procedures for Rebalancing An RDFI should recognize that it may receive
a Batch and File); IAT debits and be prepared in advance to handle
the IAT debits. The RDFI for Inbound IAT debits
• Investigate suspect transactions:
should:
– For a suspect transaction cleared by the
• Review all incoming IAT debits for OFAC
investigation:
compliance. (NOTE: Use of the Gateway
Operator Screening Indicator field by the
1. 
Populate the Gateway Operator OFAC
Gateway is optional. An RDFI should not assume
Screening Indicator (Field 10, IAT Entry
a transaction is clean because of the presence of
Detail Record) for clean transactions with
a “0” in the Gateway Operator OFAC Screening
“0.” (NOTE: This field is Optional under
Indicator (Field 10, IAT Entry Detail Record), or
the NACHA Operating Rules, but its use is
because of the absence of any indicator in this
strongly encouraged);
field. The RDFI should rely on the results of its
own investigation.);
2. Batch cleared transactions and send to the
ACH Operator for normal processing and
• Post clean transactions normally, and within
settlement.
the timeframes required under the NACHA
Operating Rules;
– For transactions confirmed as an OFAC hit:
• Investigate any suspect IAT debits:
1. Cease processing of the entry;
– For a suspect transaction cleared by an
2. Notify the Foreign Gateway that the debit
investigation, post normally;
entry has been rejected and is in violation
of U.S. law;
– For a suspect transaction confirmed as an OFAC
hit — contact OFAC directly. The Gateway
3. Notify OFAC within 10 days;
may have missed this transaction or the OFAC
list may have been revised. OFAC will handle
4. Notify the RDFI that the transaction destined
these situations on a case-by-case basis.
for one of its customers has been rejected,
and provide a copy of the transaction.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG19
SECTION I – General Information
C H A P T E R 3   O FA C R E Q U I R E M E N T S A N D O B L I G AT I O N S

Under these processing guidelines, there should Secondary OFAC Screening Indicator. These fields
be no instances in which an RDFI receives an are optional and may or may not be populated.
inbound IAT debit in which there is a “1” in the The Gateway Operator OFAC Screening Indicator
OFAC Screening Indicator. This does not relieve indicates the results of a Gateway screen for OFAC
the RDFI of its obligation to screen the IAT debits compliance. A value of “0” indicates that the
that it receives and report SDN hits to OFAC. Gateway has not found a potential blocked party,
as identified by OFAC on the SDN list. A value of
If an RDFI receives notification from a Gateway “1” indicates the potential presence of a blocked
than an inbound IAT debit destined for one of its party. [Field formatting – This field must be space
accounts has been rejected due to the presence filled if no screening has been conducted.]
of a blocked party (as described in the Gateway
Responsibilities section), the RDFI should take Inbound IAT Transactions Coming
appropriate due diligence measures. into the U.S.
If the IAT transactions enter the U.S. ACH through
DEBIT BLOCKS AND FILTERS the Federal Reserve FedACH International Service,
A number of financial institutions currently offer Field Ten will be populated by the Federal Reserve
a debit block service to their corporate customers. as the Gateway. If the IAT transaction enters the
For an IAT debit that is not in violation of an OFAC U.S. ACH through any other Gateway, the decision
sanctions program, an IAT debit processed against to populate these fields is optional. If Field Ten
an account with a debit block may be returned as has been populated, its information should not be
unauthorized as with any other debit transaction. changed, even if a suspect transaction has been
For an IAT debit that is in violation of an OFAC reviewed and cleared. If a secondary party to the
sanctions program, contact OFAC directly before transaction does another OFAC review of the file,
the debit is returned. OFAC has indicated that the results of the additional review should be
it wants to address this issue on a case-by-case placed in Field Eleven.
basis.
The Secondary OFAC Screening Indicator indicates
NOTE: Any entry that is identified as a potential the results of a Third-Party Service Provider screen
hit against the SDN list must be handled as for OFAC compliance. A value of “0” indicates that
an exception item, requiring investigation the Third Party Service Provider has not found a
and closer examination by the RDFI. Such potential blocked party, as identified by OFAC on
transactions may not be automatically returned by the SDN list. A value of “1” indicates the potential
the RDFI. presence of a blocked party. [Field formatting:
This field must be space filled if no screening has
IAT OFAC SCREENING INDICATOR been conducted].

A financial institution should only use the OFAC

ACCOUNT SCREENING
Screening Indicators as a reference and not the final
determining factor in an OFAC review. As in the The issue of screening accounts for the purpose
wire transfer procedures, each financial institution of identifying any account-holding parties subject
that is party to the transaction is responsible for to blocking action is a critical one. Depository
doing an OFAC review of the transaction. While financial institutions and other enterprises with
the actual OFAC review of the transaction may be customers that make or receive financial or
handled by a third-party, OFAC has been very clear other trade transactions are accountable if their
that a financial institution may not contract away customers are blocked parties on the SDN List.
its legal liability for OFAC compliance.
OFAC makes the current SDN List available to
Within the IAT Entry Detail Record, two fields have the public on its web site http://www.treas.gov/
been identified as OFAC Screening Indicators. offices/enforcement/ofac/.
Field Ten is identified as the Gateway Operator
OFAC Screening Indicator and Field Eleven is the Some financial institutions have the capability
to download this list directly into their account

OG20 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 4  GENERAL RULES

systems as changes are made to the list and/or on Generally, regulators stress the importance of 1)
a periodic basis to ensure that the current version assessing the nature of risks associated with ACH
is being applied to review their account base and activity; 2) performing appropriate know-your-
to verify new customers. There are also several customer due diligence; 3) establishing controls for
vendors that have OFAC account-level screening Originators, third-parties, and direct-access to ACH
solutions from which a wide range of services are Operator relationships; and 4) having adequate
available. Regardless of whether an internal or a management, information and reporting systems
third-party option is used, the objectives are the to monitor and mitigate risk.
same:
The following list includes examples of recent
• Running existing or new accountholder risk-management requirements and guidance by
information against the SDN List to identify regulators:
those accounts or applicants that involve the
interests of a blocked party (resulting in a “hit”); • OCC Bulletin 2006-39, Automated Clearing
and House Activities, September 1, 2006 (see http://
www.occ.treas.gov/ftp/bulletin/2006-39.pdf);
• Reviewing information about a “hit” to establish
whether the identification is valid, if necessary • FFIEC’s BSA/AML Examination Manual, 2007
contacting OFAC for verification (caution: more edition (see http://www.ffiec.gov/bsa_aml_
“false” hits than “true” hits are likely, given infobase/documents/BSA_AML_Man_2007.pdf,
close approximations in the names or aliases pages 199 through 205);
of individuals or companies on the SDN List
with the names of legitimate individuals or • OCC Bulletin 2008-12, Payment Processors,
companies); and, freezing and reporting to April 24, 2008 (see http://www.occ.treas.gov/
OFAC those accounts that are “true” hits. ftp/bulletin/2008-12.html);

BLOCKING AND REPORTING • FDIC Financial Institution Letter 127-2008,

ACH TRANSACTIONS Payment Processor Relationships, November
Procedures for Blocking and Reporting of 7, 2008 (see http://www.fdic.gov/news/news/
transaction in violations of an Economic Sanctions financial/2008/fil08127.html)
program can be found in 31 C.F.R. Part 501 –
Economic Sanctions Enforcement Guidelines. • FFIEC Guidance on Risk Management of Remote
Deposit Capture, January 14, 2009 (see http://
A copy of this document can be found on the www.ffiec.gov/pdf/pr011409_rdc_guidance.
OFAC website at http://www.treas.gov/offices/ pdf).
enforcement/ofac/.
RECORDS AND RECORD RETENTION
The NACHA Operating Rules permit ACH
CHAPTER 4 participants to retain ACH records electronically
as an alternative to retaining such documents in
General Rules hard copy format. Specifically, the Rules allow any
record, including any agreement, authorization, or
Written Statement of Unauthorized Debit, required
RISK ASSESSMENTS to be in writing by the NACHA Operating Rules
The Rules require all Participating DFIs to conduct to be created and retained in either hard copy or
a risk assessment of their ACH activities, and to electronic form. The electronic record must (1)
implement risk management programs based on accurately reflect information contained within
the results of such assessments, in accordance the record, and (2) be capable of being accurately
with the requirements of their regulator(s). reproduced for later reference, whether by
transmission, printing, or otherwise.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG21
SECTION I – General Information
CHAPTER 4  GENERAL RULES

Electronic Signatures and Records accurately reflect the information contained within
Electronic records include agreements, the document and that both the electronic record
authorizations, Written Statements of Unauthorized and a record of the authentication can be accurately
Debit, or other records created, generated, reproduced for future reference.
transmitted, communicated, received, or stored by
electronic means. Electronic records may have a ACH participants should be aware that other ACH
signature requirement. participants may also utilize electronic methods to
obtain and retain records of ACH documents. In
Electronic signatures are electronic sounds, such cases, the participants can expect to receive
symbols, or processes attached to or logically electronic versions, rather than hard copies, of
associated with an agreement, authorization, documents that they request from other ACH
Written Statement of Unauthorized Debit, or other participants.
record executed or adopted by a person with
the intent to sign the record. The writing and EXCUSED DELAY
signature requirements contained in the NACHA The NACHA Operating Rules provisions regarding
Operating Rules can be satisfied by compliance excused delay help clarify circumstances in which
with the Electronic Signatures and Global a processing delay by a Participating DFI or an
National Commerce Act (E-Sign Act), including ACH Operator would be excused. The Rules
the provisions that reference state versions of the permit a Participating DFI or ACH Operator to
Uniform Electronic Transactions Act. delay performance of its obligations under the
Rules beyond required time limits if:
To satisfy the requirements of the NACHA Operating
Rules (and Regulation E for preauthorized debits), 1. 
the delay was caused by the interruption of
electronic signatures must “similarly authenticate” communication or computer facilities; and
the electronic records. The authentication method
chosen must evidence both the signer’s identity and 2. the delay was beyond the reasonable control of
his assent to the terms of the record. For purposes the Participating DFI or ACH Operator seeking
of the NACHA Operating Rules, ACH records may the excused delay.
also be similarly authenticated using the same
authentication methods currently prescribed Delay by an ACH Operator beyond the time
for consumer debit authorizations — that is, the limits prescribed or permitted by the Rules also is
record may be similarly authenticated via the excused to the extent the delay was caused by the
Internet through the use of a digital signature, interruption or the suspension of payment by, or
PIN, password, shared secret, etc., or a hard copy unavailability of funds from, a Participating DFI or
record may be authenticated via the telephone by another ACH Operator.
recording the consumer’s speaking or key-entering
a code identifying the signer. Whether a delay is beyond the reasonable control
of the party asserting an excused delay must
Any other written notice or disclosure required be determined based on the available facts and
by the NACHA Operating Rules but not requiring circumstances surrounding the delay, including
a signature may also be provided in electronic whether the Participating DFI or ACH Operator
form, including e-mail. (Please note that state and exercised the level of diligence required under
Federal laws may require consumer consent before such circumstances. A delay caused, in whole or
using electronic notices/disclosures.) in part, by the default, misconduct or negligence of
a Participating DFI or ACH Operator, including the
Record Retention failure to maintain or implement an appropriate
ACH participants are permitted to retain copies of disaster recovery and business continuity plan, is
ACH records in electronic form. Those participants not excused under the Rules for that Participating
using electronic methods to retain ACH records DFI or ACH Operator.
should implement practices and procedures to
ensure that electronic records of ACH documents

OG22 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION I – General Information
CHAPTER 4  GENERAL RULES

A delay that is excused will continue to be excused of the NACHA Operating Rules governing excused
until either the cause of the delay has been delay is consistent with general guidance from the
eliminated or should have been eliminated (if the Federal Financial Institutions Examination Council
affected Participating DFI or ACH Operator had (FFIEC) regarding contingency backups, which
exercised the level of diligence required under the states that “All computer installations must make
circumstances), whichever is earlier. formal arrangements for alternative processing
capability . . .”
A Participating DFI or ACH Operator asserting an
excuse from any delay under the Rules should, as Financial institutions and ACH Operators should
promptly as possible after discovery, notify other have back-up systems in place to protect against
ACH participants of the delay and its reliance on delays caused by computer failure. However, the
the Rules to excuse such delay. The notice may be failure of a DFI’s or ACH Operator’s systems due
given directly to affected ACH participants, through to circumstances beyond their control may still
membership organizations such as Regional constitute an excused delay.
Payment Associations, through an ACH Operator if
the ACH Operator agrees to distribute such notice, ACH DATA SECURITY REQUIREMENTS
or through other methods reasonably designed to
For all ACH transactions that involve the exchange
notify the affected ACH participants.
or transmission of banking information (which
includes, but is not limited to, an entry, entry data,
If an ACH participant affected by a delay wishes
a routing number, an account number, and a PIN
to challenge whether a Participating DFI or ACH
or other identification symbol) via an Unsecured
Operator has properly claimed an excused delay,
Electronic Network, the NACHA Operating Rules
the participant may do so using the National System
require that such banking information be either:
of Fines, as with any other alleged rules violation.
The party asserting the excused delay bears the
1. 
encrypted using a commercially reasonable
burden of proving that the delay is properly
security technology that, at a minimum, is
excused. NACHA may consider all available facts
equivalent to 128-bit RC4 encryption technology,
and circumstances in making a determination,
or
including:
2. transmitted via a secure session that utilizes
1. the cause of the delay;
a commercially reasonable security technology
that provides a level of security that, at
2. 
the applicable provisions of the disaster
a minimum, is equivalent to 128-bit RC4
recovery and business continuity plan that
encryption technology.
were intended to prevent and/or mitigate the
delay, including whether the event causing the
For purposes of the NACHA Operating Rules and
delay was reasonably foreseeable and whether
the ACH Network, an Unsecure Electronic Network
the disaster recovery and business continuity
is a network, public or private, that:
plans were properly implemented; and
1. is not located entirely within a single, contiguous,
3. 
the actions being taken to remedy the
physical facility; and
situation.
2. either (a) transmits data via circuits that are not
Operational outages due to the general failure
dedicated to communication between two end-
or interruption of communication or computer
points for the duration of the communication,
facilities or other equipment do not constitute an
or (b) transmits data via wireless technology
excused delay for a Participating DFI, its Third-
(excluding a communication that begins and
Party Service Provider, or an ACH Operator. DFIs
ends with a wireline connection, but that is
and ACH Operators must expect that computer
routed by a telecommunications provider for
problems will occur and make contingency plans to
a portion of the connection over a wireless
handle such situations. In this regard, the section
system).

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG23
SECTION I – General Information
CHAPTER 4  GENERAL RULES

FIGURE 4-1

For clarity, the Internet is an Unsecure Electronic of any banking information exchanged over such
Network, even though secure transmissions may an Unsecured Electronic Network between:
be made over that otherwise unsecure network.
1. an Originator and a Receiver;
A secure Internet session is one that is typically
indicated by the secure access symbol on the 2. an Originator and an ODFI;
bottom menu bar of the browser (e.g., a padlock).
For security purposes, a secure Internet session will 3. an ODFI and an ACH Operator;
generally expire after a certain period of inactivity,
at which time the user will be required to reenter 4. an ACH Operator and an RDFI; and
the login credentials initially used to enter the
secure Internet session. Currently, 128-bit RC4 5. 
an Originator, ODFI, RDFI, or ACH Operator
encryption technology is the standard for financial and a Third-Party Service Provider.
transactions and is considered commercially
reasonable. If technological advancements Transmissions of banking information over an
drive the commercially reasonable standard to Unsecured Electronic Network by means of voice
change, Originators should comply with the new or keypad inputs from a wireline or wireless
standard. telephone to a live operator or voice response unit
are not subject to this data security requirement.
Figure 4-1 above depicts the concept of a secure An application in which the Originator obtains
Internet session. information from the Receiver by another means
(such as the telephone) and then key enters the
These encryption requirements must be employed information via the Internet is, for example, subject
prior to the key-entry and through the transmission

OG24 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 5   R E L AT I O N S H I P W I T H O D F I

to these data security requirements. However,

information delivered via telephone line, such as
a leased line, or dialed into a financial institution’s SECTION II

Originating
modem pool is not subject to this requirement.

The NACHA Operating Rules also require ODFIs

to utilize commercially reasonable methods
to establish the identity of each Originator or Depository
Financial
Third-Party Sender that uses an Unsecured
Electronic Network, such as the Internet, to enter
into a contractual relationship with the ODFI
for the origination of ACH transactions. Such a
requirement helps to ensure that ODFIs employ
measures to know the Originators or Third-Party
Institutions
Senders with whom they establish relationships
over Unsecured Electronic Networks and to verify
those Originators’/Third-Party Senders’ identities. PA R T T W O

COMMERCIALLY REASONABLE RIGHTS AND RESPONSIBILITIES

STANDARD OF ORIGINATORS
A commercially reasonable system, technology,
practice, or procedure is one that corresponds to
commonly-accepted commercial practices among An Originator initiates entries into the Automated
commonly situated parties conducting similar Clearing House Network through a relationship
types of transactions. The concept of commercial with an Originating Depository Financial Institution
reasonableness means that a party, given the (ODFI) or a Third-Party Sender. The ACH Network
facts of a specific transaction, acted in a way that enables an Originator to prepare a batch of debit
other similar parties would have acted. Whether and/or credit entries to transfer funds via the ACH
a party has fulfilled its obligations to perform in from or to Receivers’ accounts.
a commercially reasonable manner is determined
Third-Party Senders are discussed in Chapter
based on an evaluation of the circumstances.
21 of these Guidelines.
Accordingly, what constitutes a commercially
Examples of Originators are:
reasonable system, technology, practice or
procedure may change over time. For example,
• An employer offering its employees direct
as new technology becomes available or costs
deposit of payroll or an organization (company,
of certain technologies or procedures decrease,
financial institution) offering direct deposit of
new standards of commercial reasonableness may
funds (interest, dividends, retirement funds,
evolve. Therefore, ACH participants need to work
etc.).
together to ensure continued compliance. The
person challenging the use of a particular system,
• A company or billing firm that offers direct
technology, practice or procedure has the burden
payment (debits) to those consumers that owe a
of establishing that the system, technology, practice
recurring or one time obligation.
or procedure employed by a particular party was
not commercially reasonable.
• An organization that consolidates or disburses
funds from or to its subsidiaries or branches.

• A corporate entity that enters into a trading

partner agreement with a corporate receiver for

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG25
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 5   R E L AT I O N S H I P W I T H O D F I

the purpose of transferring funds according to ELECTRONIC RECORDS AND

that agreement. RECORD RETENTION
The NACHA Operating Rules permit ACH
• A merchant or financial institution that offers
participants to retain ACH records electronically
point of sale activity to consumers.
as an alternative to retaining such documents in
hard copy format. Specifically, the Rules allow any
• An individual that initiates an entry via a bill
record, including any agreement, authorization, or
payment service to a company for monies
Written Statement of Unauthorized Debit, required
owed.
to be in writing by the NACHA Operating Rules
to be created and retained in either hard copy or
• A company converting to electronic payments
electronic form. The electronic record must (1)
business or consumer checks received via the
accurately reflect information contained within
U.S. Mail or at a dropbox location.
the record, and (2) be capable of being accurately
• A company converting eligible checks presented reproduced for later reference, whether by
for payment at the point of purchase to electronic transmission, printing, or otherwise.
payments.
Electronic records and record retention are
• A company electronically re-presenting checks addressed in Chapter 4 of these Guidelines.
that have been returned for insufficient or
uncollected funds.

The primary participant relationships for the CHAPTER 15

Originator are with the Receiver and the ODFI or
Third-Party Sender. The Originator’s relationship
Relationship with ODFI
with the ODFI and the Receiver involves both
legal responsibilities and processing issues. The
secondary relationship for the Originator is with AGREEMENT WITH ODFI AND USE OF
its Third-Party Service Provider. THIRD-PARTY SENDERS
Each Originator must execute an agreement
ACH DATA SECURITY with the ODFI or Third-Party Sender before
the ODFI originates entries on its behalf.1 This
The NACHA Operating Rules impose specific data
origination agreement defines the parameters of
security requirements for all ACH transactions that
the relationship between the two parties. At a
involve the exchange or transmission of banking
minimum the Origination Agreement must:
information (which includes, but is not limited to,
an entry, entry data, a routing number, an account
1. bind the Originator to the Rules;
number, and a PIN or other identification symbol)
via an Unsecured Electronic Network. Originators
2. provide the Originator’s authorization for the
must abide by these requirements.
ODFI to originate entries on behalf of the
Originator to the Receiver’s accounts;
ACH data security requirements are discussed
in detail in Chapter 4 of these Guidelines.
3. provide for the Originator’s agreement not to
originate entries that violate the laws of the
United States;

1
The NACHA Operating Rules do not require an ODFI/Originator
agreement for Customer Initiated Entries (CIE). For more information
on CIE, refer to Chapter 40 of these Guidelines.

OG26 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

4. include any restrictions on the types of entries Relationship With ODFI in this section. Detailed
that may be originated; information on OFAC compliance can be found in
Section I of these Guidelines.)
5. include the right of the ODFI to terminate or
suspend the agreement upon no more than Originators should interface with their ODFIs via
ten Banking Days’ notice for the Originator’s a secured telecommunications link for all ACH-
breach of the Rules; and related activity. This includes the origination and/
or receipt of all current ACH entries and related
6. provide for the right of the ODFI to audit the reports and any future related applications.
Originator’s compliance with the origination
agreement and the Rules.

When a Third-Party Sender acts as an intermediary CHAPTER 16

between the Originator and the ODFI for the
origination of ACH transactions, the ODFI and Relationship with Receiver and
Third-Party Sender must enter into an origination Authorization Requirements
agreement that, among other things, obligates the
Third-Party Sender (i) to comply with the NACHA
Operating Rules and (ii) to enter into an agreement The type of authorization arrangement entered into
with the Originator that includes at least the same between the Receiver and the Originator depends
provisions required by the origination agreement upon the type of application that is being initiated.
between the Originator and the ODFI; and (iii) to Corporate applications, where the Originator
annually conduct an audit of its compliance with and Receiver have entered into a trading partner
the Rules. agreement, could require more intricate terms
than consumer applications. For example, the
The agreements between the Originator and corporate application could include the processing
an ODFI or Third-Party Sender also should of payment related data or may be used to transfer
identify processing requirements for the large dollar amounts.
specific applications, and establish liability and
accountability for certain procedures related to MINIMUM AUTHORIZATION
the applications. In some instances, provisions of
REQUIREMENTS/PROPER USE OF
the agreement may be superseded by applicable
STANDARD ENTRY CLASS CODE
federal or state law (e.g., Uniform Commercial
Code Article 4A or the Electronic Fund Transfer The authorization requirements specified within
Act). the Rules address the minimum requirements
needed for authorization of various types of ACH
Please see Appendix C of these Guidelines for a entries. The Rules permit ACH participants to
list of issues that the Originator and its ODFI obtain authorization in a manner that exceeds the
may specifically define in their origination minimum requirements, provided that all other
agreement. requirements for that particular type of entry are
met. As an example, the rule provisions related to
Originators must be aware that they are subject to certain types of electronic check transactions (e.g.
applicable U.S. law when initiating ACH Entries. ARC and BOC) provide that Originators may obtain
This includes, among other things, that the authorization by notice to the Receiver. In such
Originator is not violating the Office of Foreign cases, Originators may also obtain a signed, written
Assets Control (OFAC)-enforced sanctions, and is authorization, provided that all other requirements
not acting on behalf of, or transmitting funds to for the type of entry are met. Originators will need
or from, any party subject to such sanctions. (For to consider the impact of other requirements on
additional information about OFAC requirements any change in the manner of authorization chosen
as they relate to Originators, refer to the discussion for a particular type of payment to ensure that
on Processing Requirements and Responsibilities – they are also compliant with those requirements.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG27
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

For instance, although written authorization is MICR line is not appropriate for ACH activity. In
permissible for BOC Entries, notice would still be addition, some financial institutions may provide
required to comply with Regulation E. their customers with another source document
that indicates the routing and account number
When the Rules specify requirements for entries to be used for ACH entries.
to be authorized in a particular way, the Rules also
specify the minimum requirements that Originators In an effort to help ensure the proper routing and
must follow for each entry initiated in that particular processing of ACH Entries, Originators should
manner. The Rules explicitly require the use of the consider implementing practices and procedures
appropriate Standard Entry Class Code for such that will enable them to verify the accuracy
entries. For instance, an Originator that wishes to of routing numbers prior to the transmission
convert a check received at the point of purchase of entries into the ACH Network. Originators
to an ACH debit during back office processing may must be aware that, in certain circumstances,
only use the BOC Standard Entry Class Code and such as with TEL entries and WEB entries, the
must comply with the Rules related to such entries. NACHA Operating Rules specifically require an
No other Standard Entry Class Code may be used Originator to establish commercially reasonable
for such purposes. procedures to verify that routing numbers are
valid.
CONSUMER RECEIVERS
• The authorization should indicate whether it
In general, the Originator must obtain the
relates to entries directed to a demand deposit
Receiver’s authorization to initiate entries through
account, a savings account, a loan account or a
the ACH Network to the Receiver’s account. The
general ledger account. (Note: NOW accounts
authorization must (1) be readily identifiable as
and sharedraft accounts are transaction
an ACH authorization; (2) have clear and readily
accounts within the broad category of demand
understandable terms; and (3) provide that the
accounts.)
Receiver may revoke the authorization only by
notifying the Originator in the manner specified in
• The Originator must obtain authorization for
the authorization.
both consumer credit and debit entries. However,
when both the Originator and Receiver are
Originators of entries to consumer accounts must
natural persons, Receiver authorization is not
meet the following authorization requirements:
required for credit entries. This is an exception
to the credit authorization requirement.
• Account numbers and routing numbers must be
accurately stated.
Authorization for Credit Entries
Originators may use the on-us field of the MICR Consumers may provide authorizations for credit
line of a check to obtain the account number entries in writing, or they may be provided orally
for ACH entries. Originators must ensure that or by other non-written means. As noted above,
the correct Receiver’s account number is if both the Originator and Receiver are natural
contained in each ACH entry. Originators are persons, no Receiver authorization is required.
strongly encouraged to establish practices and
procedures to ensure the validity and accuracy Authorization for Debit Entries
of each Receiver’s account number for all entries All debits to consumer accounts must be authorized
transmitted into the ACH Network. by the consumer via a writing that is signed or
similarly authenticated by the consumer, with
Originators should also look on the face of a the exception of ARC, BOC, and RCK entries.
check for the routing information. Some financial The authorization requirements for ARC, BOC,
institutions may print the routing number and RCK, and TEL entries to consumer accounts are
account number used for ACH purposes on the discussed separately below.
face of the document, if the information on the

OG28 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

Originators of debit entries to consumer accounts and the consumer, but the consumer has
must comply with the following criteria to ensure initiated the telephone call to the Originator. For
proper authorization of consumer debits under the a Single Entry TEL, the Originator must either
NACHA Operating Rules: make an audio recording of the consumer’s
oral authorization or provide the Receiver with
Copy of Authorization – With the exception of
•  written notice confirming the oral authorization
ARC, BOC, and RCK entries, the Originator must prior to the Settlement Date of the entry. For a
obtain the consumer’s written authorization. recurring TEL entry, the Originator must make
This authorization may be sent to the consumer an audio recording of the consumer’s oral
by mail, fax, or Internet/on-line network, or it authorization and provide the Receiver with a
may be provided to the consumer in person. In written copy of the authorization prior to the
circumstances where the consumer signs the Settlement Date of the first entry. The Originator
written authorization or, alternatively, uses the must provide the ODFI with the original, copy,
telephone to similarly authenticate the written or other accurate record of the Receiver’s
authorization by speaking or key entering a code authorization in such time and manner as to
identifying himself, the consumer has a paper enable the ODFI to deliver the authorization to
authorization in his possession, which he should the RDFI within ten banking days of the RDFI’s
retain as his copy of the authorization. The request.
consumer can also request an additional hard
copy of the authorization from the Originator. For ARC, BOC, and RCK entries, authorization
For the Internet/on-line network alternative, consists of notice from the Originator to the
the consumer reads the authorization that consumer and the receipt of the consumer’s
is displayed on the computer screen or other source document (for ARC and BOC entries) or
visual display. The consumer should print the item (for RCK entries) by the Originator.
authorization from his computer screen and
retain this copy. The Originator must be able P
lease refer to the chapters on ARC,
to provide the consumer with a hard copy of a BOC, and RCK entries for specific notice
debit authorization if requested to do so. requirements.

F
 or ARC entries for an in-person bill payment 
For a Return Fee Entry – that is, a debit entry to a
at a manned location and for BOC entries, the consumer’s account for the purpose of collecting
Originator must provide a copy of the notice or a Return Fee – the Originator must obtain the
substantially similar language to the Receiver at Receiver’s authorization prior to initiating the
the time of the transaction. Return Fee Entry. This can be accomplished in
either of two ways:
For POP entries, the Originator must obtain the
Receiver’s written authorization, as discussed (1) Authorization by Notice – Originators
above, and must also provide the Receiver with may obtain authorization for a Return Fee
notice at the point of purchase or manned bill Entry by providing the Receiver/check
payment location. writer with notice that conforms to the
requirements of Regulation E at the time

Please refer to Chapters 37, 38, and 44 on that the underlying ACH debit is authorized
ARC, BOC and POP entries, respectively, for or the underlying check is accepted. Please
specific notice requirements. refer to the chapter on Return Fee Entries
for specific notice requirements.
F
 or TEL entries, the consumer’s authorization
may be obtained orally via the telephone for (2) Authorization other than by Notice –
debits where there is (1) an existing relationship Originators may also obtain authorization
between the Originator and the consumer, or (2) for a Return Fee Entry in any other form
no existing relationship between the Originator permitted by the Rules, dependent upon

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG29
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

the Standard Entry Class Code used for the minimum information must be included as
debit Entry to a Consumer Account (e.g., part of the authorization:
written authorization for PPD or WEB,
oral authorization for TEL). - t he amount of the recurring transactions or a
reference to the method of determining the
Please refer to Chapter 54 for more detailed amounts of recurring transactions;
information on authorization and specific
notice requirements for Return Fee Entries. - t he timing (including the start date), number
and/or frequency of the electronic fund
• Minimum Information Requirements – For transfer, or other similar reference, to the
all entries, the authorization must be readily consumer’s account;
identifiable as an ACH debit authorization and its
terms must be clear and readily understandable. - the Receiver’s name or identity;
With the exception of POP, the writing must
specify that the Receiver may revoke the - the account to be debited;
authorization only by notifying the Originator
in the manner specified on the authorization - a telephone number for Receiver inquiries
form. that is answered during normal business
hours;
– For Single Entry TEL entries, the following
minimum information must be included as - t he manner in which the Receiver can revoke
part of the authorization: the authorization; and

- the date on or after which the ACH debit to - the date of the Receiver’s oral authorization.
the Receiver’s account will occur;
• Authentication of Authorization – With the
- t he amount of the transaction, or a reference exception of ARC, BOC, RCK, and Return Fee
to the method of determining the amount of Entries entries, the authorization must be signed
the transaction; or similarly authenticated by the consumer.

- the Receiver’s name or identity; Similarly Authenticated

The similarly authenticated standard permits
- the account to be debited; signed, written authorizations to be provided
electronically. These writing and signature
- a telephone number for Receiver inquiries requirements are satisfied by compliance with
that is answered during normal business the Electronic Signatures in Global and National
hours; Commerce Act (15 U.S.C. 7001 et seq.).

- t he manner in which the Receiver can revoke To satisfy the requirements of Regulation E and
the authorization; the NACHA Operating Rules, the authentication
method chosen must evidence both the consumer’s
- the date of the Receiver’s oral authorization; identity and his assent to the authorization.
and
Examples of methods used to similarly authenticate
- a statement by the Originator that the an authorization include, but are not limited to, the
authorization obtained from the Receiver use of digital signatures, codes, shared secrets, PINs,
is for a Single-Entry ACH debit, a one-time etc. Authentication of an authorization is strongest
electronic funds transfer, or other similar when the authorization and the authentication of
reference. that authorization occur simultaneously or nearly
simultaneously. Although an initial website session
– For recurring TEL entries, the following log-in may constitute adequate authentication for

OG30 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

a click-through authorization as part of the same at least ten calendar days before the scheduled
session, Originators and ODFIs should consider transfer date. Additionally, if the Originator
the strength of the association of an initial log- informs the consumer of the right to receive notice
in with a later authorization. The Originator and of all varying transfers, the consumer may elect to
ODFI bear the burden of demonstrating that the receive notice only when a transfer does not fall
authentication process is sufficiently linked to the within a specified range of amounts. Alternatively,
authorization. the consumer may elect to receive notice only when
a transfer differs from the most recent transfer by
Appendix H of these Guidelines outlines more than an agreed upon amount.
acceptable alternatives for authenticating the
consumer’s authorization. If the Originator changes the date on or after which
a recurring debit entry to a consumer account
Retention of Authorization is scheduled to be debited, the Originator must
The Originator must retain an original or copy of send the Receiver written notification of the new
a written authorization, and readily and accurately date. The Originator must send the notice at least
reproducible records evidencing any other form of seven (7) calendar days before the first entry to be
authorization. The record of authorization must affected by the change is scheduled to be debited
be retained by the Originator for a period of two to the Receiver’s account.
years following the termination or revocation of the
authorization. The authorization may be retained Copy of Authorization
as an electronic record that (1) accurately reflects The Originator, upon request of the ODFI, must
the information in the record, and (2) is capable present the original, copy or other accurate record
of being accurately reproduced for later reference, of the customer’s authorization to an ODFI for its
whether by transmission, printing, or otherwise. use or use by the RDFI. The RDFI should not ask
for the customer authorization as a normal course
Multiple, Non-Recurring Debits of business but only if an exception is expected or
Multiple but non-recurring debits are debits in has occurred.
which the amount and time frame for the initiation
of the debits may vary. Examples of this type of Data Passing
debit include occasional catalog purchases from The Restore Online Shoppers’ Confidence Act
the same merchant or occasional purchases of prohibits a merchant from initiating an Internet
securities with a broker. Originators do not need to transaction unless the merchant has obtained
obtain a written authorization for each individual certain authorization information, including
debit entry. However, they must have obtained a account number and consumer’s name and
written authorization up front that establishes a address, directly from the consumer. This law also
relationship between the Originator and consumer prohibits a merchant from disclosing a customer’s
Receiver for this particular type of activity and to account number and other billing information to
which all such entries would apply. another merchant for use in an Internet-based sale.

Notice of Change in Amount/Change in Effective March 15, 2013, the NACHA Operating
Debiting Date for Recurring Debits to Consumer Rules will be modified to protect customers from
Accounts such potentially confusing practices. NACHA will
When the amount of a recurring debit to a adopt a rule that is similar to those currently in
consumer account varies, specific requirements effect in major card brand rules. This rule will
apply. If a preauthorized debit transfer varies from be broader in scope than the requirements of The
the immediately preceding transfer relating to the Restore Online Shoppers’ Confidence Act in that it
same authorization or from a fixed preauthorized is not limited to Internet transactions.
amount, the Originator must send the Receiver
written notification of the amount and the date The Rules will be revised to 1) prohibit an ODFI
on or after which of the transfer will be debited from disclosing a consumer Receiver’s account
number or routing number to any third party for

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG31
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

use in initiating a debit Entry that is not part of the underlying check is accepted. Any notice
the original authorization; and 2) require the ODFI meeting the form, process, and content permissible
to ensure that the Originator and any Third-Party under Regulation E satisfies this authorization
Service Provider do not disclose such information requirement, even though the account to be
for use in initiating a debit Entry that is not part of debited is a non-Consumer account.
the original authorization.
Please see chapter 54 on Return Fees for specific
CORPORATE RECEIVERS authorization and notice requirements.

Agreements/Authorizations for
Remittance Information/Non-Monetary
Corporate Transactions
Entries
As with consumer entries, the business Receiver
The nature of the agreement between the Originator
must authorize all ACH credits and debits to its
and Receiver will include additional terms if the
account. An Originator must enter an agreement
application includes the processing of payment-
with each business Receiver of entries (other than
related data along with the payment.
ARC, BOC and POP Entries to non-consumer
accounts) under which the Receiver has agreed to Non-Monetary Entries are entries that carry no
be bound by the NACHA Operating Rules. The settlement value but do include payment-related
nature of the agreement for corporate transactions remittance data. Examples of Non-Monetary
can vary depending upon the complexity of the Entries include CTX and CCD entries that carry
application and the relationship between the remittance information indicating a credit position
Originator and the Receiver. The Originator of the Originator to the Receiver or relating to a
that is collecting or disbursing funds to its own period of time during which no funds are owed by
subsidiaries, for example, may require an entirely the Originator to the Receiver. Originators must
different agreement for the funds transfer than it ensure that corporate trading partner agreements
would if it were entering into a trading partner include provisions for remittance data to be sent
agreement with another corporation. via the ACH Network for either live dollar or Non-
Monetary Entries.
With respect to ARC and BOC entries, authorization
consists of notice from the Originator to the
Corporate Debits
business Receiver and the receipt of the business’
Eligible Source Document. For POP entries, Originators of corporate debits to Receivers other
authorization is comprised of both the Receiver’s than their own subsidiaries need to be aware of
written authorization and notice regarding the the sensitivity of this application. Many corporate
check conversion policy provided to the Receiver Receivers are reluctant to allow debit activity to
by the Originator at the point of purchase or their accounts; therefore, it is imperative that
manned bill payment location. the agreement that supports this type of activity
is complete and accurate. Originators may be
Specific information on authorization and required to provide some proof that debit activity
notice requirements for ARC, BOC, and POP was, in fact, authorized if a transaction is questioned
entries can be found in Chapters 37, 38 and by the Receiver.
44, respectively, of these Guidelines.
ORIGINATING ACH ENTRIES
As with other entries, a Return Fee Entry to a Originators that use the various ACH applications
non-Consumer account must be authorized by must be sure to comply with the requirements
the Receiver. For a Return Fee related to an ARC, associated with the particular application. Each
BOC or POP Entry, the Originator may obtain entry type has specific conditions that must be met
the Receiver’s authorization by providing the in order for the entry to be considered properly
Receiver/check writer with notice that conforms authorized.
to the requirements of Regulation E at the time
that the underlying ACH debit is authorized or

OG32 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

Originating ARC Entries • Retain a copy of the front of the Eligible Source
When originating an ARC Entry, an Originator Document for 2 years, and provide it to the
must: ODFI upon request;

• Prior to accepting each check, provide the • Securely store the Eligible Source Document
Receiver with a conspicuous notice that has until destroyed; and
clear and readily understandable terms;
• Maintain a telephone number for customer
• Provide a copy of the notice, or language that is inquiries.
substantially similar, to the Receiver at the time
of the transaction when the source document Originating CCD Entries
for the ARC Entry is provided by the Receiver When originating a CCD Entry to a non-consumer
in-person for payment of a bill at a manned account, an Originator must:
location;
• Obtain the corporate Receiver’s authorization to
• Obtain an eligible source document (i.e., a originate entries to the Receiver’s account and
check) via the U.S. mail, dropbox, delivery
service or in person for payment of a bill at a • Obtain the corporate Receiver’s agreement to be
manned location; bound by the NACHA Operating Rules.

• Use a reading device to capture MICR Originating a POP Entry

information; When originating a POP Entry, an Originator
must:
• Retain a copy of the front of the Eligible Source
Document for 2 years, and provide it to the • Provide the Receiver with a conspicuous notice
ODFI upon request; and that has clear and readily understandable
terms;
• Securely store the Eligible Source Document
until destroyed. • Obtain an Eligible Source Document at the point
of the in-person transaction;
Originating BOC Entries
When originating a BOC Entry, an Originator • Use a reading device to capture MICR
must: information;

• Provide the Receiver with a conspicuous notice • Void the Eligible Source Document and return it
that has clear and readily understandable to the Receiver;
terms;
• Obtain a written, signed authorization; and
• Provide a copy of the notice or substantially
similar language to the Receiver at the time of • Provide a copy of the notice at the time of the
the transaction; transaction.

• Obtain an Eligible Source Document at the point Originating PPD Entries

of the in-person transaction; When originating a PPD debit Entry to a consumer
account, an Originator must:
• Verify the identity of the Receiver;
• Provide the Receiver with a written authorization
• Use a reading device to capture MICR that is readily identifiable as an ACH debit
information; authorization and contains clear and readily
understandable terms.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG33
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 6   R E L AT I O N S H I P W I T H R E C E I V E R A N D A U T H O R I Z AT I O N R E Q U I R E M E N T S

• Obtain the Receiver’s agreement to the terms of Originating TEL Entries

the authorization via his signature or electronic When originating a TEL Entry to a consumer
signature equivalent (i.e., the authorization must account, an Originator must:
be similarly authenticated).
• Obtain oral authorization from the Receiver via
• Obtain the Receiver’s authorization for a Return the telephone. The authorization must be readily
Fee Entry originated using the PPD Standard identifiable as an authorization and must have
Entry Class Code by either (1) obtaining the clear and readily understandable terms.
Receiver’s written authorization, or (2) providing
the Receiver with the required notice. • Provide the required minimum information as
part of the authorization.
For detailed information on Return Fee Entries
and authorization requirements, please refer • For Single-Entry TEL entries, make an audio
to Chapter 54 within the Special Topics section recording of the oral authorization, or provide
of these Guidelines. the Receiver with written confirmation of the
oral authorization prior to the Settlement Date
When originating a PPD credit Entry to a consumer of the entry. The Originator must also retain a
account, an Originator must: reproducible copy of the recording or written
confirmation of the authorization for 2 years
• Obtain an authorization from the Receiver that from the date of the authorization.
is readily identifiable as an authorization and
has clear and readily understandable terms. • For recurring TEL entries, make an audio
Authorization for a PPD credit entry is not recording of the oral authorization, and
required to be in writing. provide the Receiver with a written copy of the
authorization prior to the Settlement Date of
Originating RCK Entries the first entry. The Originator must also retain
When originating an RCK Entry to a consumer for 2 years from termination or revocation of
account, an Originator must: the authorization (1) the original or a duplicate
audio recording of the oral authorization and
• Agree with its ODFI that any restrictive (2) evidence that a copy of the authorization
endorsement made by the Originator or its agent was provided to the Receiver.
on the item to which the RCK Entry relates is
void or ineffective upon initiation of the RCK • Verify the identity of the Receiver.
Entry.
• Verify that the routing number is valid.
• Provide the Receiver with a conspicuous notice
that has clear and readily understandable Originating WEB Entries
terms. When originating a WEB/Mobile Entry to a
consumer account, an Originator must:
• Use an eligible item.
• Obtain written authorization from the Receiver
• Retain a copy of the front and back of the eligible (1) via the Internet or a wireless network; or
item for 7 years, and provide it to the ODFI (2) in any manner permissible under the Rules,
upon request. If the item has been paid, the if the Receiver’s instruction for the initiation of
copy provided to the ODFI must be so marked. the debit entry is designed by the Originator
to be communicated, other than by an oral
• Not reinitiate an RCK entry more than one time communication, via a wireless network.
within 180 days of the Settlement Date of the
original entry, provided that the item to which • Use a fraudulent transaction detection system to
the RCK relates has been presented no more screen each WEB Entry.
than one time through the check collection
system, and one time as an RCK entry.

OG34 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 7   I N I T I AT I O N O F F O R WA R D E N T R I E S

• Verify the Receiver’s identity. The Rules also define specific content requirements
for the Company Name Field for transactions in
• Verify that the routing number is valid. which the party initiating the payment is not the
ultimate payee or payor of a transaction -- that is,
• Conduct annually an audit of data security where a third party is involved in the origination
practices for Receivers’ financial information. of the payment. Specifically, for any ACH debit
transaction in which the party transmitting the
entry into the ACH Network is not the payee of
the transaction (which is defined as the party to
CHAPTER 17 which payment is ultimately being directed), the
Company Name Field must contain the name by
Initiation of Forward Entries which the payee is known and readily recognized
by the Receiver. For any ACH credit transaction in
which the party initiating the entry into the ACH
PROCESSING REQUIREMENTS Network is not the payor of the transaction (which
Account Types and Transaction Codes is defined as the party from which payment is
ultimately being directed), the Company Name
The NACHA Operating Rules permit Originators to
Field must contain the name by which the payor
transmit ACH credit and debit entries to demand
is known and readily recognized by the Receiver.
accounts (i.e., checking, NOW, and sharedraft
This requirement is consistent with Regulation
accounts) and savings accounts at an RDFI. The
E, which requires an RDFI to provide the name
Rules also permit Originators to transmit both
of any third party to or from whom funds were
credit and debit entries to financial institutions’
transferred on the consumer’s periodic statement.
general ledger accounts and to transmit credit
entries only (with the exception of reversals to
The following scenarios provide examples of how
correct erroneous credit entries) to loan accounts.
the Company Name Field is to be used in a variety
Transaction Codes are used to define the type of
of payment models.
entry and the type of account to which the entry
is transmitted.
Example #1
Please refer to Appendix Three of the NACHA SmartPay, Inc., provides a variety of payment
Operating Rules for a complete list of processing services on behalf of several insurance
Transaction Codes. companies, offering lockbox services, check
conversion, ACH debit origination, and general
Company Name Identification accounts receivables and policy management
services through a centralized location. Policy
To ensure clear identification of the source of
holders deal with SmartPay directly regarding
an ACH transaction, the Rules contain specific
billing issues or questions regarding the payment
requirements with respect to how an Originator
of insurance premiums. Although SmartPay, Inc.
must identify itself within an ACH record. The Rules
handles all of the payment processing functions,
specifically require the Originator to populate the
including collecting money from policy holders, it
Company Name Field with the name by which it is
is considered to be a third party acting on behalf
known to and readily recognized by the Receiver
of each insurance company rather than the party
of the entry. This name could, for example, be the
to which funds are ultimately being directed by the
Originator’s “doing business as” name or “trading
insured. In this model, the Company Name Field
as” name. The inclusion of a readily recognizable
for any debits originated to the policy holders’
Originator name ensures that the Receiver is
accounts by SmartPay must contain the name
able to identify a transaction appearing on his
of the insurer issuing the policy and providing
periodic statement. The clear identification of the
coverage rather than SmartPay, which consolidates
Originator of an ACH transaction also improves
payments on behalf of those parties.
overall network quality by reducing the number of
unrecognized entries requiring investigation and
return by the RDFI.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG35
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 7   I N I T I AT I O N O F F O R WA R D E N T R I E S

Example #2 relationship directly with Industrial Corporation

ABC Company offers a salary redirection program or the other clients of EZPay.
to its employees for flexible spending accounts for
health and dependent care. A salary redirection In this example, EZPay is a third party involved in
agreement is executed between John Smith, an the origination of ACH transactions on behalf of
employee of ABC Company, and FSA4U, the plan the actual Originators of the payment, where there
administrator for ABC Company’s flexible spending is no contractual relationship directly between
account program. Under this agreement, Mr. Smith the ODFI and each Originator. Under the NACHA
authorizes the plan administrator to initiate ACH Operating Rules, EZPay is considered to be a
entries and agrees to submit specific documentation Third-Party Sender. Although EZPay initiates the
to the plan administrator prior to the origination payroll files into the ACH Network through its own
of an ACH credit. In an IRS-defined salary deferral account at its own financial institution, it must
program of this type, the plan administrator has a identify Industrial Corporation and its other clients
direct contractual relationship with the employee as the Originators of the payroll files to ensure
and his or her authorization to initiate ACH credits the entries can be recognized by the companies’
to support this program and would be identified in employees and for purposes of complying with
the Company Name Field of the entry. Regulation E, which requires the name of the
third party from which funds are transferred to be
Example #3 provided on the employees’ bank statements.
Miss Johnson decides to place a catalog order
with TrailsEnd, an outdoor outfitter, and visits the Example #5
company’s website for more information. While Mr. Jones uses the internet to establish an account
there, she places her order for camping supplies relationship with InstaPay, an online bill payment
and authorizes payment to be made electronically service provider serving hundreds of consumers.
from her checking account. Later that month, Mr. Jones provides instructions to InstaPay
when she receives her bank statement, she regarding the specific bills to pay each month.
notices a debit entry that she doesn’t recognize Today, Mr. Jones also instructs InstaPay to send
from Outdoors, Inc. Miss Johnson signs a Written a payment to ABC Credit Card Bank to pay his
Statement of Unauthorized Debit and requests her monthly credit card bill. InstaPay pays ABC Credit
bank to recredit her for this entry, as she has never Card Bank for the amount due from Mr. Jones and,
heard of Outdoors, Inc. She later discovers that through its own financial institution, initiates a
Outdoors, Inc. is the parent company for TrailsEnd debit entry to Mr. Jones’ checking account at First
and realizes that the debit was for her earlier Bank and Trust. Even though InstaPay initiated the
internet purchase. In this situation, the Company debit entry into the ACH Network through its own
Name Field should have identified TrailsEnd as the financial institution, it is acting in the capacity of a
Originator — a name that would have been readily third party on behalf of the ultimate payee. In this
known to and recognized by Miss Johnson — and example, InstaPay must identify ABC Credit Card
not the name of the parent company. Bank (rather than itself) in the Company Name
Field of the debit to Mr. Jones’ account to ensure
Example #4 that Mr. Jones can properly identify the payment
and to ensure compliance with Regulation E, which
Industrial Corporation, a large manufacturing
requires the RDFI to identify on the consumer’s
firm, outsources the processing of its employee
statement the third party to which funds are
payroll and expense reimbursement to EZPay ACH
transferred.
Services. EZPay also offers similar services to many
other corporate clients, consolidating the work of
Industrial Corporation and those other companies Company Identification
and originating transactions through EZPay’s own The Company Identification number is agreed upon
account at Super DFI. Super DFI has an account by the ODFI and the Originator, and is used by
relationship and an ACH origination agreement the ODFI to identify its customer (the Originator).
directly with EZPay, but it does not have any However, this number is also used by many RDFIs
to help identify originating companies that debit or

OG36 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 7   I N I T I AT I O N O F F O R WA R D E N T R I E S

credit Receiver’s accounts, particularly with respect OFAC Regulations

to stop payment orders. ODFIs should keep in The U.S. Treasury Department’s Office of Foreign
mind that using consistent Company Identification Assets Control (OFAC) administers economic
numbers for their Originators is helpful to the sanctions and embargo programs that require that
RDFI and Receiver in properly identifying the assets and transactions involving the interests of
source of entries. target countries, target country nationals, and other
specifically identified companies and individuals
ACH Data Security Requirements (“blocked parties”) be frozen. All of the programs
In addition to the ACH Data Security requirements administered by OFAC involve declarations of
discussed in Chapter 4, Originators have additional national emergency by the President of the United
obligations under the Rules regarding the secure States.
storage and destruction of banking information.
Like other payment mechanisms, the ACH Network
The Rules require that Originators of ARC and BOC is subject to compliance with OFAC regulations.
entries employ commercially reasonable methods All U.S. citizens and permanent resident aliens,
to securely store all related source documents companies located in the U.S., overseas branches
until these source documents are destroyed by the of U.S. companies, and, in some cases, overseas
Originator. Originators are also obligated to use subsidiaries of U.S. companies come under OFAC
commercially reasonable methods to securely store jurisdiction. In terms of the ACH Network, this
all banking information related to ARC and BOC means that all U.S. ACH participants, including
entries. Banking information includes, but is not Originators, ODFIs, RDFIs, and Receivers need to
limited to, an entry, entry data, a routing number, be aware that they may be held accountable for
an account number, PINs and other identification violations of OFAC sanctions and must understand
symbols, etc. their compliance obligations.

Processing Relationship with ODFI Detailed information relating to OFAC

The ODFI and the Originator must mutually Regulations and their impact on Originators
determine how the payment information will flow can be found in Chapter 3 of these Guidelines.
from the Originator into the ACH Network and
what the role of the ODFI will be regarding the Identification Numbers
processing of that information. The role of the The Company Identification Number, which
ODFI will vary depending on the following: appears in the Company/Batch Header record, is
agreed upon by the originating company and the
• the level of sophistication of the ODFI and the ODFI. It is common practice to use one of the
Originator in processing ACH entries; ANSI standard identifiers indicating what type of
number is used. The ANSI standard identifiers are:
• the ability of the Originator to generate the “1” (indicating an IRS number); “3” (indicating a
payment information in ACH format; DUNS number); or “9” (indicating a user-assigned
number).
• the nature of the payment application;
The Individual ID Number is the number assigned
• the policy of the ODFI regarding the use of a by an Originator for internal control (e.g., an
Third-Party Service Provider; employee number, customer billing number,
customer internal account number, etc.). No more
• the policy of the ODFI regarding the use of than 15 characters of identification can be used
Sending Points other than the ODFI; and for this purpose. (Spaces and dashes are included
in the count of 15.) The Individual ID Number is
• the involvement of Third-Party Senders in the used in the Entry Detail Records of several ACH
origination of ACH entries. applications.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG37
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 7   I N I T I AT I O N O F F O R WA R D E N T R I E S

Testing Procedure • Company Name fields containing the words

ODFIs should test ACH files from Originators to “CHECK DESTROYED” (for XCK entries).
ensure that they are either in the proper NACHA
format or in the alternative format that has been The use of invalid characters will cause the batch
agreed upon. The level of testing is determined by that contains the invalid character(s) to reject.
the complexity of the application.
Input Schedules/Availability of Funds
The more complex the payment application, the An Originator must adhere to the schedules
greater the testing requirement. For example, established by the ODFI for input of ACH files.
the Originator that is transmitting corporate These schedules are set so that the ODFI can deliver
transactions that include multiple addenda records files to the ACH Operator for timely distribution
will need to establish a level of testing with the and settlement. The Originator should be aware
ODFI that reflects the agreed upon parameters of of any modification of the schedule for instances
the services that are to be provided by the ODFI. where the expected Settlement Date falls on a
weekend or holiday. Warehousing of ACH entries
ODFIs should take appropriate measures to ensure by the ODFI prior to delivery to the ACH Operator
that test data is not inadvertently entered into the is sometimes an option for Originators that wish to
live production system or that live files are not prepare files early.
held in test mode.
Adherence to input schedules will ensure
Invalid Characters compliance with certain rules and regulations. For
The Originator must ensure that no invalid example, when credits are originated, the NACHA
characters are included in ACH files. Characters Operating Rules require that the RDFI make funds
used in ACH records are limited to 0-9, A-Z, a-z, available for withdrawal or cash withdrawal on the
space, and those special characters which have Settlement Date. Funds must be made available
an EBCDIC value greater than hexadecimal “3F” for withdrawal or cash withdrawal at the opening
or an ASCII value greater than hexadecimal “1F.” of business on Settlement Date for PPD credit
EBCDIC values “00”-”3F” and ASCII values “00” - entries that are made available to an RDFI by its
“1F” are not valid. Upper case characters must be ACH Operator by 5:00 p.m. (RDFI’s local time) on
used for all of the following: the banking day prior to the Settlement Date. ACH
Operators offer a variety of input schedules that
• all alphabetic characters within the Standard support availability of files to RDFIs by a certain
Entry Class Code field; time each day. Every Originator must determine
with its ODFI which input schedule will ensure
• all alphabetic characters within the File ID that the RDFIs can receive files and make funds
Modifier field; available, particularly for sensitive entries such
as direct deposit of payroll, by the opening
• all alphabetic characters within the Change of business on Settlement Date. Regulation E
Code and Refused COR Code fields; obligates the RDFI to post certain transactions to
consumer accounts as of the payment date and
• all alphabetic characters within the Return requires employees’ statements to reflect, among
Reason Code, Dishonored Return Reason Code, other things, that posting date.
and Contested Dishonored Return Reason Code
fields; Settlement
Effective Entry Date/Settlement Date
• Company Entry Description fields containing the
The Effective Entry Date in the Company Batch
words “NONSETTLED,” “RECLAIM,” “RETURN
Header Record is specified by the Originator as
FEE,” “REVERSAL,” “AUTOENROLL” (for ENR
the date on which settlement for entries in that
entries), “REDEPCHECK” (for RCK entries), and
batch is expected to occur. The Settlement Date
“NO CHECK” (for XCK entries); and

OG38 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 7   I N I T I AT I O N O F F O R WA R D E N T R I E S

is inserted in the Company/Batch Header Record Returns, Reinitiation of Entries, Notifications of

by the Receiving ACH Operator; it represents the Change, Rejected Files
Julian date on which settlement is scheduled to The Originator and ODFI must determine how
occur for the transactions contained in that batch. the Originator wants to receive information on
The Receiving ACH Operator determines the returned entries and notifications of change. The
Settlement Date based on the Effective Entry Date ODFI must also establish procedures for notifying
and the current ACH processing date. the Originator if a file or batch has been rejected,
particularly in the case where it might be necessary
Stale-Dated Entries for the Originator to recreate the file or batch.
Although the ACH Operator will accept stale-dated
entries, it is not recommended that Originators The NACHA Operating Rules preclude an
insert a stale date in the Effective Entry Date field. Originator or ODFI from reinitiating a returned
When a stale date is used, the actual Settlement ACH entry unless (1) the entry has been returned
Date will not be the same as the Effective Entry for insufficient or uncollected funds; (2) the entry
Date, but instead will be the next available business has been returned for stopped payment and
day (at least one day after the Effective Entry Date). reinitiation has been authorized by the Receiver, or
This occurs when the batch was delivered to the (3) the ODFI has taken corrective action to remedy
ACH Operator with an Effective Entry Date that the reason for the return. The NACHA Operating
is the same or earlier than the date on which the Rules impose a limit on the number of times and
ACH Operator processes the file. For example, a the time period within which an entry returned for
batch carrying an Effective Entry Date of March 15, insufficient or uncollected funds may be reinitiated
20xx would settle on the next available business by an Originator or its ODFI. Specifically, entries
day if March 15 were to fall on a Saturday, Sunday, returned for these reasons may be reinitiated a
or holiday. Use of a stale date can cause confusion maximum of two times following the return of the
at the RDFI because the Effective Entry Date and original entry. This limit is effective for all Standard
the Settlement Date would not be the same. Also, Entry Class Codes except RCK, which has its own
return entries carry the Effective Entry Date, not distinct limit on the number of presentments. An
the Settlement Date of the original entry. Originator or ODFI may reinitiate such returned
entries only within 180 days of the Settlement Date
Warehousing of the original entry.
The Originator and ODFI must ensure that ACH
entries are not delivered to the ACH Operator too Processing Relationship with Receiver
early. ACH credit transactions can be submitted to The Originator will usually develop a processing
the ACH Operator one or two business days prior relationship with the Receiver only when the
to the Effective Entry Date. ACH debit transactions two parties have entered into a trading partner
can be submitted to the ACH Operator one business agreement for the transfer of funds and payment-
day prior to the Effective Entry Date. related information. When agreeing to format
and remittance information requirements with its
For example, ACH credits with an Effective Entry Receiver, the Originator is encouraged to make
Date of March 15, 20xx could be submitted to the Receiver aware that it may obtain all payment-
the ACH Operator for processing on March 14 related information transmitted within the addenda
or March 13, 20xx. If submitted on March 12 or records of CCD, CTX, CIE entries, and IAT entries
earlier, the batch would be rejected. Similarly, ACH to non-consumer accounts, provided that the
debits carrying an Effective Entry Date of March Receiver requests such information from its RDFI.
15, 20xx cannot be submitted to the ACH Operator
prior to March 14, 20xx. The Originator and ODFI
must determine if ACH entries should be held
(warehoused) by the ODFI until the appropriate
date on which they can be delivered to the ACH
Operator. (The above examples assume that all
dates are business days.)

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG39
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 8   O R I G I N AT O R S A N D R E T U R N A N D D I S H O N O R E D R E T U R N E N T R I E S

Returns for Revocation of Authorization

CHAPTER 18
In a debit application, entries may be returned
Originators and Return and by the RDFI as R07 - Authorization Revoked
Dishonored Return Entries by Customer. This code can be used when the
Receiver has provided the RDFI with a Written
Statement of Unauthorized Debit in which the
Receiver states that the authorization for the debit
PREPARING TO RECEIVE RETURNS
entry was revoked directly with the Originator
Entries initiated into the ACH Network, either under the terms and conditions set forth in the
prenotification entries or live dollar entries, may authorization agreement. The Originator may
be returned for specific reasons. These reasons are request that its ODFI obtain a copy of the Written
defined by Return Reason Codes. Some codes are Statement of Unauthorized Debit from the RDFI,
used solely by the ACH Operator, while others are when appropriate. The ODFI’s written request
used when a return is originated by an RDFI. It is for such a copy must be received by the RDFI
essential that the Originator work closely with its within one year of the date on which the Extended
ODFI to establish procedures for handling returns. Return Entry was initiated by the RDFI. The RDFI
With the exception of IAT entries, addenda records must comply with the ODFI’s request for a copy
are not returned. For example, the Originator of the Written Statement of Unauthorized Debit
initiates a CTX entry that carries addenda records. within ten days of receiving the ODFI’s written
If the CTX entry is returned, it will be returned request for such a document. Originators may
without the original addenda records. IAT return not reinitiate entries returned for authorization
entries must include the original seven mandatory revoked and should be prepared to contact the
addenda records. Receiver regarding those entries.

A complete list of Return Reason Codes and their Returns of Unauthorized/Improper

uses appears in Appendix Four of the NACHA Consumer Debit Entries
Operating Rules.
Unauthorized Consumer Debit Entries
RETURN TYPES Originators can expect the return of entries that
were not properly authorized. An unauthorized
Returns for Insufficient Funds debit entry is an entry in which:
In a debit application, entries can be returned by
the RDFI if there are not funds in the Receiver’s • the authorization requirements have not been
account to cover the debit entry, i.e., insufficient followed in accordance with the Rules or invalid
funds (NSF) or if there are uncollected funds so under applicable legal requirements.
the entry cannot be honored. The specific Return
Reason Codes used by the RDFI are R01 for NSF • a transaction was initiated in an amount different
and R09 for uncollected funds. These codes are than that authorized by the Receiver;
unique in that entries returned with the codes can
be re-originated through the ACH Network. The • a transaction was initiated for settlement earlier
Originator will want to make arrangements with its than authorized by the Receiver.
ODFI for the handling of debit entries returned for
NSF or uncollected funds. Originators should note In general, consumer debit entries returned by
that the NACHA Operating Rules impose a limit on the RDFI as unauthorized will bear Return Reason
the number of times that an entry returned for Code R10 and must be returned by the RDFI in such
insufficient or uncollected funds may be reinitiated. time and manner that the return is made available
Detailed information on the reinitiation of returned to the ODFI no later than the opening of business
entries can be found later in this chapter. on the banking day following the sixtieth calendar
day following the Settlement Date of the original
entry. (Note: This return deadline is the same as

OG40 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 8   O R I G I N AT O R S A N D R E T U R N A N D D I S H O N O R E D R E T U R N E N T R I E S

the return deadline for the return of debit entries In certain business arrangements, a Third-Party
for which the consumer Receiver had previously Sender initiates a debit entry to a consumer’s
revoked his authorization, which are transmitted account to fund a corresponding payment (e.g.,
using Return Reason Code R07 – Authorization an ACH credit) to a payee. For example, Third-
Revoked). Party Senders may be involved in origination of
utility payments, bill payments, tuition payments,
At times, Originators may erroneously transmit ACH etc. In situations where a Third-Party Sender
Entries that are formatted using an incorrect SEC debits a consumer Receiver but does not complete
Code. This is in violation of the NACHA Operating the intended transaction by paying the Receiver’s
Rules. The Rules allow the RDFI to rely on the obligation to the payee, the underlying transaction
ODFI’s warranty that the SEC Code included in the is incomplete (an “Incomplete Transaction”).
entry is proper and obligates the RDFI to use the Incomplete Transactions create service issues for
return rules and time frames associated with that RDFIs, particularly when a Third-Party Sender fails
particular SEC Code. to perform its obligations across a large number of
customers.
However, for an unauthorized debit to a consumer
account that bears a corporate SEC Code (i.e., This rule amendment will permit a consumer
CCD or CTX), the RDFI may be unable to meet Receiver to request, and require the RDFI
the time frame for return because the return to provide, re-credit for a debit Entry to the
time frame for corporate entries may have lapsed Receiver’s account when it is part of an Incomplete
before the consumer can receive his statement Transaction. The rule will also specifically provide
and notify his RDFI about the unauthorized debit for the return of such a debit by the RDFI, putting
to his account. In order to enable the RDFI to the obligation for the debit back with the ODFI
treat all unauthorized debits to consumer accounts where it rightfully belongs. The request for re-
in a consistent manner, regardless of SEC Code, credit and the RDFI’s return of a debit related to
the NACHA Operating Rules define a specific an Incomplete Transaction will be subject to the
Return Reason Code R05 (Unauthorized Debit to same requirements and time frames currently
Consumer Account Using Corporate SEC Code) that defined within the Rules for the recredit and
the RDFI may use to return unauthorized entries return of an unauthorized debit to the Receiver’s
to a consumer account that bear a corporate SEC account. Specifically, the rule will require an RDFI
Code. Returns bearing Return Reason Code R05 to recredit a consumer Receiver for a debit that is
must be transmitted by the RDFI in such time and part of an Incomplete Transaction if the consumer
manner that the return is made available to the has provided a Written Statement of Unauthorized
ODFI no later than the opening of business on the Debit. The RDFI will be required to transmit a
banking day following the sixtieth calendar day return in such time and manner as to be made
following the Settlement Date of the original entry. available to the ODFI no later than the opening of
Prior to transmitting returns bearing this return business on the Banking Day following the sixtieth
code, the RDFI must obtain a Written Statement of calendar day following the Settlement Date of the
Unauthorized Debit from the consumer. debit Entry. The description of Return Reason Code
R10 (Customer Advises Not Authorized, Improper,
Incomplete Transactions and the Return of or Ineligible) will be expanded for this purpose.
Funding Debit Entries
Effective March 15, 2013, the Rules will be amended As a result of this change, Originators may benefit
to allow the return of a debit Entry to a consumer from a better resolution of the interruption of
account within 60 days of the Settlement Date their customers’ payments. When Originators’
for an “Incomplete Transaction.” An Incomplete customers are re-credited by their RDFIs, these
Transaction is defined as a transaction for customers will be in a position to make alternative
which a Third Party Sender debits a consumer’s payment arrangements with Originators.
account to collect funds, but does not complete
the corresponding payment to the party to which
payment is owed.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG41
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 8   O R I G I N AT O R S A N D R E T U R N A N D D I S H O N O R E D R E T U R N E N T R I E S

Ineligible/Improper Consumer Debit Entries • Ineligible entries: An ineligible ARC, BOC or

Originators may also expect the return of entries POP entry is one in which the source document
that were ineligible for ACH origination or that related to the entry does not meet the criteria for
were originated improperly. an eligible source document under the NACHA
Operating Rules. Business checks that bear an
• Ineligible entries: An ineligible ARC, BOC, Auxiliary On-Us Field in the MICR line and that
POP or RCK entry is one in which the source are in an amount of $25,000 or more are not
document related to the entry does not meet eligible for conversion. For more information on
the criteria for an eligible source document eligible and ineligible source documents, please
under the NACHA Operating Rules. For more see the chart provided in Appendix E of these
information on eligible and ineligible source Guidelines.
documents, please see the chart provided in
Appendix E of these Guidelines. • Improper entries: An improper ARC, BOC or POP
entry is one in which the source document related
• Improper entries: An improper ARC, BOC, to the entry meets the eligibility requirements,
POP or RCK entry is one in which the source but a condition of the authorization for the
document related to the entry meets the particular entry has not been met. Article Three,
eligibility requirements, but a condition of the subsection 3.12.2 addresses improper ARC, BOC
authorization for the particular entry has not and POP entries.
been met. Article Three, subsection 3.12.2
addresses improper ARC, BOC, POP and RCK Returning Unauthorized, Ineligible or
entries. Improper Debits
Unauthorized, ineligible or improper debit entries
Returns of Unauthorized/Improper to business accounts may be returned by the RDFI
Corporate Debits in one of three ways. The RDFI may return any
unauthorized debit as Return Reason Code R29
Unauthorized Corporate Debits (Corporate Customer Advises Not Authorized).
As with debits to consumer accounts, Originators Returns bearing the R29 Return Reason Code must
can expect the return of entries to business be received by the RDFI’s ACH Operator by its
accounts that were not properly authorized or that deposit deadline for the return entry to be made
were improperly originated. available to the ODFI no later than the opening
of business on the second banking day following
An unauthorized debit entry is an entry in which: the Settlement Date of the original entry. If an
RDFI receives written notification from a Receiver
• the authorization requirements have not been after the time for return has expired that a CCD or
followed in accordance with the Rules or are CTX debit entry to the Receiver’s account was not
invalid under applicable legal requirements; authorized by the Receiver, the RDFI may transmit
a permissible return entry to the ODFI, provided
• a transaction was initiated in an amount different that the ODFI has agreed, either verbally or in
than that authorized by the Receiver; writing, to accept the late return entry. Such a
return must be transmitted using Return Reason
• a transaction was initiated for settlement earlier Code R31 (Permissible Return Entry). If the
than authorized by the Receiver. unauthorized debit to the business account bears
a consumer SEC Code, or if the check conversion
Ineligible/Improper Debits to Corporate entry was ineligible or improperly originated, the
Accounts RDFI may also transmit the return using return
Originators may also expect the return of entries reason code R10. The RDFI must transmit such a
to corporate accounts that were ineligible for ACH return in such a time and manner that the return
origination or that were originated improperly. is made available to the ODFI no later than the
opening of business on the banking day following
the 60th calendar day following the Settlement
Date of the entry.

OG42 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 8   O R I G I N AT O R S A N D R E T U R N A N D D I S H O N O R E D R E T U R N E N T R I E S

Stop Payments PROCESSING GUIDELINES FOR

Originators may receive entries that are returned RETURN ENTRIES
because the Receiver has placed a stop payment In addition to being knowledgeable about specific
order on the ACH entry or associated source Return Reason Codes, the Originator should:
document. A stop payment order may be for one,
several or all future entries. Since the Originator • Establish schedules with its ODFI for the receipt
cannot determine the Receiver’s intent based on of return data.
the Return Reason Code R08 - Stop Payment alone,
the Originator should contact the customer for this • Establish procedures for handling returns for
information. The Originator may not reinitiate the NSF or uncollected funds.
returned entry unless the reason for the return is
remedied. • Establish procedures with the Receiver for an
appropriate course of action should an entry be
Returns for Death of Beneficiary, returned:
Representative Payee, or Account Holder
Entries may be returned by the RDFI if the credits – an alternate form of payment may be
RDFI has become aware of the death of the appropriate until the reason for the credit return
beneficiary, representative payee, or account is researched and resolved.
holder. Originators should be aware of the specific
differences between Return Reason Codes R14 and debits – an alternate form of collection may
R15 to ensure that returns bearing these codes are be appropriate if a debit entry is returned,
handled appropriately by the Originator. depending upon the reason for return.

Originators should be aware that returns bearing • Establish a deadline for accepting debit returns
Return Reason Code R14 - Representative Payee after which debit returns will be dishonored. A
Deceased or Unable to Continue in that Capacity return can be dishonored as untimely only if the
are transmitted when the representative payee return was not initiated within the appropriate
assigned to receive benefit payments on behalf of time frames, and only if the ODFI or Originator
the entitled individual has died. A representative has suffered a loss.
payee is a person or institution authorized to
accept entries on behalf of one or more other REINITIATION OF RETURN ENTRIES
persons, such as legally incapacitated adults or An Originator may reinitiate an entry that was
minor children. Returns bearing Return Reason returned if:
Code R14 indicate that the representative payee,
and not the beneficiary of the payments, has died. • the entry was returned for insufficient or
The beneficiary is not deceased and is still entitled uncollected funds (the entry cannot be reinitiated
to the benefit payments. This Return Reason more than two times following the return of the
Code should not be used unless a representative original entry);
payee exists.
• the entry was returned for stopped payment and
Returns bearing Return Reason Code R15 - reinitiation has been authorized by the Receiver;
Beneficiary or Account Holder [Other Than a or
Representative Payee] Deceased will indicate
either (1) in the case of benefit payments where no • the Originator has taken corrective action to
representative payee has been assigned, the actual remedy the reason for the return.
beneficiary is deceased, or (2) in the case where the
payment is not a benefit payment (i.e., insurance Reinitiation must take place within one hundred
premium debit), the owner of the account has died eighty days after the Settlement Date of the original
and the payment is being returned by the RDFI. Entry.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG43
SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 9   O R I G I N AT O R S A N D P R E N O T I F I C AT I O N S A N D N O T I F I C AT I O N S O F C H A N G E

Note: Special requirements apply to the reinitiation provided for within the NACHA Operating Rules
of RCK entries. See Chapter 46 for more and as outlined below.
information.
A prenotification entry may be originated at
DISHONORED RETURNS any time. If an Originator chooses to transmit
prenotification entries, however, it may not initiate
The Originator may have its ODFI dishonor a
live dollar entries until at least six banking days
return for specific reasons, which fall into two
following the Settlement Date of the prenotification
categories as follows:
entry. The prenote must carry an appropriate
Effective Entry Date to be processed through the
• The return entry is untimely.
ACH system (it is not the date of the first live
entry). Any prenotification entry with an Effective
• The return entry contains incorrect information.
Entry Date that falls outside of the processing
window will be rejected by the ACH Operator just
The Originator should be aware, however, that
as it would if it were a live entry.
the RDFI may contest a dishonor that has been
issued for an untimely return, or it may initiate a
The format of a prenotification entry is the same
corrected return. If an Originator fails to utilize
as a live dollar entry, except in the Entry Detail
the Dishonored Return process, such failure does
Record, in which the dollar amount is zero and the
not preclude its right to seek recovery against
transaction code indicates a prenotification entry.
an RDFI outside of the ACH return process for a
Prenotification entries may be intermingled within
late return.
a batch of credit and/or debit live dollar entries.
The Transaction Codes for prenotification entries
are:

CHAPTER 19 23  Prenotification for DDA credit.

Originators and Prenotifications 28  Prenotification for DDA debit.
and Notifications of Change 33  Prenotification for Savings credit.
38  Prenotification for Savings debit.
43  Prenotification for General Ledger credit.
PRENOTIFICATIONS
48  Prenotification for General Ledger debit.
A prenotification is a Non-Monetary Entry sent
through the ACH Network by an Originator to an 53  Prenotification for Loan Account credit.
RDFI. It conveys the same information (with the
exception of the dollar amount and transaction Response to Prenotification Returns and
code) that will be carried on subsequent entries, Notifications of Change
and it allows the RDFI to verify the accuracy of the There are three ways that an Originator can receive
account data. a response to a prenotification. The prenotification
can be:
Prenotification Process
Use of the prenotification process by an Originator • returned by the ACH Operator as unprocessable;
is optional for all Standard Entry Class Codes.
Since the prenotification process helps to ensure • returned by the RDFI; or,
that subsequent entries to a Receiver’s account at
an RDFI are posted appropriately, an Originator • result in the origination of a Notification of
may initiate a prenotification entry for any ACH Change (NOC) from the RDFI.
transaction. In choosing to transmit prenotification
The response to the prenotification will determine
entries, however, an Originator must fulfill all
the Originator’s course of action.
other requirements relating to prenotifications as

OG44 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 1 9   O R I G I N AT O R S A N D P R E N O T I F I C AT I O N S A N D N O T I F I C AT I O N S O F C H A N G E

• If a prenotification is returned by the ACH corrections within six banking days of receipt of
Operator, then the Originator should be aware the NOC information or prior to initiating another
that the RDFI has never received the prenote. entry to the Receiver’s account, whichever is later.
The Originator should research the reason for Originators should not wait six banking days
the return and make any necessary corrections if the change can be made earlier – they should
before transmitting another entry. make the change prior to initiating the next entry,
if possible. Originators should be thoroughly
• If a prenotification is returned by the RDFI, then familiar with the NOC Change Codes and their
the Originator should research the problem meanings. Originators should work with their
according to the Return Reason Code contained ODFIs to agree upon the method by which NOC
on the return entry and make any necessary information will be provided by the ODFI (e.g., via
corrections prior to transmitting a subsequent electronic media, paper format, etc.) and should
entry. ensure that they have a thorough understanding of
how to interpret NOC provided by their financial
• If a prenotification results in a Notification institutions.
of Change, then the Originator should make
the required change within six banking days NOC Change Codes generally fall into two
of receipt of the NOC information or prior to categories:
initiating another entry, whichever is later, or
issue a Refused Notification of Change. • 
Codes that indicate an error in the account
information – entries carrying these codes
NOTIFICATIONS OF CHANGE indicate that the RDFI did receive the entry
but the account information or information
A Notification of Change (NOC) is a Non-Monetary
regarding the Receiver was incorrect. Changes
Entry transmitted by an RDFI to the Originator
must be made so that the RDFI can handle the
through the ODFI. It is created when the RDFI
entry appropriately.
receives a prenotification or a live dollar entry that
contains incorrect information. A Notification of
• Codes that indicate an error in the routing of
Change:
the entry – entries carrying these codes indicate
that the routing information must be changed.
• identifies the entry that has been received at the
Failure to change the routing information could
RDFI;
cause subsequent entries to that particular
account to be delayed or returned. An Originator
• pinpoints the specific information on that entry
should not assume, however, that a change to
that is incorrect; and
a routing number affects all ACH transactions
going to that routing number. For example, if
• provides the correct information in a precise
a financial institution buys some branches of
format so the Originator can make the change.
a failed institution, it might initiate NOCs only
Notifications of Change have a unique Standard for those specific accounts they have now taken
Entry Class Code, COR, and a unique Addenda over. The original routing number may be valid
Type Code, “98”. for other accounts.

A complete list of change codes for Notifications Originators should monitor Notifications of
of Change appears in Appendix Five of the Change that are received to determine whether
NACHA Operating Rules. their enrollment procedures need to be modified.

When identifying the original entry referenced in

Responsibilities of Originators
an NOC, Originators should be aware that, when
Originators must respond to Notifications of an account or branch has been sold to another
Change by investigating incorrect data and making RDFI, the routing number in the Receiving DFI

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG45
SECTION II – Originating Depository Financial Institutions
C H A P T E R 2 0   O R I G I N AT O R S A N D R E V E R S A L S A N D R E C L A M AT I O N S

Identification field of the original entry may not reversing file can include an entire file or a number
match the routing number in the Originating DFI of batches that constitute a segment of a file. A
Identification field of the NOC. However, the reversing file should only reverse those batches
RDFI’s routing number from the original entry that were duplicate or erroneous.
can be located in the Original Receiving DFI
Identification field in the addenda record of the Duplicate Files
NOC. A duplicate file is a file that was erroneously
introduced into the ACH Network twice. Duplicate
An Originator should be familiar with the Refused files are exact in that all data within the two files are
Notification of Change process for its ODFI to notify exactly the same, including effective entry dates,
the RDFI that it cannot process the Notification of trace numbers, dollar amounts, etc. Therefore, the
Change. Procedures must be established between Receiver was erroneously paid (credits) or charged
the Originator and the ODFI for the origination (debits) twice.
of Refused NOCs, which must be in automated
format. Erroneous Files
An erroneous file is one in which the information
within a substantial number of the entries was
incorrect. For example, the Receivers’ account
CHAPTER 20
numbers could all be invalid, causing the entries
Originators and Reversals to be posted or rejected incorrectly, or the dollar
and Reclamations amount could have been incorrectly calculated,
causing the Receiver to be credited or debited
incorrectly.
Once an entry or file of entries has been transmitted
into the ACH Network, it cannot be recalled, but Procedures
an erroneous or duplicate file may be reversed. If It is the responsibility of the party that originated
a single entry has been duplicated or originated the duplicate or erroneous file to reverse that file.
erroneously, the ODFI may either request the Each reversing file must be in the format required
RDFI to return the entry or transmit a reversing by ACH specifications. When a file is reversed due
entry. Reversal capability allows fast, efficient, and to duplication or error, the Originator or ODFI
accurate recovery from an error. Originators can must:
initiate a reversal, depending upon the reason for
the reversal. • Initiate the reversing file so that it can be
transmitted or made available to the RDFI(s)
An Originator may initiate a reclamation entry for within 5 banking days after the Settlement Date
pension, annuity or other benefit payments by for the entries within the duplicate or erroneous
PPD, as provided for in sections 2.10 (Reclamation file.
Entries and Written Demands for Payment) and
3.6.2 (Liability of RDFI for Reclamation Entries • Place the word “REVERSAL” in the Company
and Written Demands for Payment) of the NACHA Entry Description Field of each Company/Batch
Operating Rules, if; Header Record.

• the Receiver is deceased; and • Transmit the file to the Originating ACH Operator
within 24 hours of the discovery of the error.
• neither the Receiver’s estate nor any other
account holder is entitled to the payment. • Initiate a correcting file with the reversing file, if
the file is reversing an erroneous file.
FILE REVERSALS
File reversals may be originated to correct a
duplicated file or an erroneous file in which
substantially all of the entries were incorrect. A

OG46 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION II – Originating Depository Financial Institutions
C H A P T E R 2 0   O R I G I N AT O R S A N D R E V E R S A L S A N D R E C L A M AT I O N S

Authorization is for funds related to a Receiver’s employment;

The rules and requirements for authorization do (ii) the value of the PPD credit is fully included
not apply for reversing files. in the amount of a check delivered to the same
Receiver at or prior to the Receiver’s separation
Additional Suggestions for Action from employment; (iii) the PPD credit entry was
transmitted by the Originator prior to the delivery
The origination of duplicate and erroneous files
of the check to the Receiver. A reversing entry
is clearly an exception condition that can cause
may be initiated under the following conditions:
confusion and mishandling of ACH entries. The
best protection against error is to ensure that
• Only an Originator may initiate a reversing
procedures are in place to reduce or eliminate the
entry.
possibility that duplicate or erroneous files will be
originated. Originators and ODFIs should:
• As required by the NACHA Operating Rules, the
Originator must make a reasonable attempt to
• take steps to ensure that all files are originated
notify the Receiver of and the reason for the
correctly;
reversing entry no later than the Settlement
Date of the reversing entry. This will ensure
• establish procedures to identify errors quickly;
that Receivers are made aware of ACH reversal
and
activity to their accounts prior to the receipt of
their periodic account statements. The NACHA
• institute methods to initiate reversing files
Operating Rules do not prescribe the method
immediately, when necessary.
(i.e., mail, telephone, fax, etc.) by which
If a file is duplicated or originated erroneously, Originators must provide notice to Receivers;
there are certain steps that an Originator and instead, the choice of method is at the discretion
ODFI can take to assist other parties that may be of the Originator.
affected:
• The reversing entry must be transmitted to
• ensure that appropriate personnel are aware the RDFI by midnight of the fifth banking day
that an error has occurred and are aware of the following settlement of the erroneous entry.
correcting action taken;
• The advance notification rule for variable amount
• contact as many parties (ACH Operator, ACH debits and the rules governing authorization
Association, RDFIs) as possible to advise them requirements do not apply to reversing
of the error and of the correcting action taken; entries. However, the Originator may consider
and, obtaining, in advance, direct authorization from
the Receiver for reversing entries.
• establish procedures to reduce the possibility
that the same error can happen again. RECLAMATIONS FOR BENEFIT
PAYMENTS
REVERSING ENTRIES An Originator or ODFI may initiate a reclamation
An Originator that originates a payment in error entry or written demand for payment for pension,
may originate a reversing entry. An erroneous annuity or other benefit payments by PPD, as
entry is an entry that (1) is a duplicate of an entry provided for in section 2.10 (Reclamation Entries
previously initiated by the Originator or ODFI; (2) and Written Demands for Payment) of the NACHA
orders payment to or from a Receiver different than Operating Rules, if:
the Receiver intended to be credited or debited by
the Originator; (3) orders payment in an amount 1. the Receiver is deceased; and
different than was intended by the Originator;
or (4) is a PPD credit entry satisfying each of 2. 
neither the Receiver’s estate nor any other
the following criteria: (i) the PPD credit entry account holder is entitled to the payment.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG47
SECTION II – Originating Depository Financial Institutions
C H A P T E R 2 1   R E L AT I O N S H I P W I T H O R I G I N AT O R S A N D O D F I s

The reclamation entry is a debit entry that must ODFI and the Originator; there is no contractual
be originated in an amount equal to or less than agreement between the Originator and the ODFI.
the pension, annuity, or other benefit payment to
which the Receiver was not entitled. ORIGINATORS
The NACHA Operating Rules require that the
The reclamation entry or written demand for
agreements between the Third-Party Sender and
payment must contain:
its Originators include at least the same provisions
required by an origination agreement between
• the name of the Receiver;
the Originator and the ODFI. The agreements
• the deceased Receiver’s account number; should also identify processing requirements for
• the exact amount of the entry being reclaimed; the specific applications, and establish liability
and and accountability for certain procedures related
to the applications. In some instances, provisions
• the approximate date the entry being reclaimed
of the agreement may be superseded by applicable
was initiated.
federal or state law (e.g., Uniform Commercial
Reclamation entries must also contain the word Code Article 4A or the Electronic Fund Transfer
RECLAIM in the Company Entry Description Field Act).
of the Company/Batch Header Record.
Please see Appendix C of these Guidelines for a
The Originator or ODFI must originate a reclamation list of issues that the Third-Party Sender and
entry or written demand for payment within five its Originator may specifically define in their
banking days after the Originator receives notice origination agreement.
of the Receiver’s death. If a reclamation entry is
returned by the RDFI, the Originator may make ODFIs
a written demand for payment within 15 banking The unique position of Third-Party Senders within
days after it receives a returned reclamation entry. the ACH transaction flow can result in increased
risk to Network participants due to the lack of
a direct contractual relationship between the
PA R T T H R E E Originator and the ODFI. The NACHA Operating
Rules require Third-Party Senders and their ODFIs
RIGHTS AND RESPONSIBILITIES to enter into originations agreements to help
OF THIRD-PARTY SENDERS protect the ODFI against credit risk by providing
them with the ability to seek recovery of payment
directly from the Originator.

The origination agreement must include each of

the following provisions:
CHAPTER 21

Relationship with Originators • The Third-Party Sender, on behalf of the

and ODFIs Originator, must authorize the ODFI to originate
entries on behalf of the Originator to Receivers’
accounts;
A Third-Party Sender is a type of Third-Party
Service Provider. It is an organization that is not • The Third-Party Sender must agree to be bound
an Originator that authorizes an ODFI or another by the NACHA Operating Rules;
Third-Party Sender to transmit credit, debit or non-
monetary entries for the account of the Third-Party • The Third-Party Sender must agree not to
Sender or another Third-Party Sender. A Third- originate entries that violate U.S. law;
Party Sender acts as an intermediary between the

OG48 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 36  ACKNOWLEDGMENT ENTRIES

• Any restrictions on the types of entries that may • 

Payment to ODFI – Each Third-Party Sender
be originated; is obligated to make payment to the ODFI for
all credit entries and for all debit entries that
• The right of the ODFI to audit the Third-Party are returned by the RDFI. In the event that the
Sender’s and its Originators’ compliance with ODFI does not receive payment from the Third-
the origination agreement and the Rules; and Party Sender, the Originator of the entry agrees
to pay the ODFI.
• The Third-Party Sender must agree that, before
permitting an Originator to originate any entry • Performance of Originator Responsibilities –
directly or indirectly through the ODFI, it will The Third-Party Sender and its Originators are
enter into an agreement with the Originator responsible for the retention and delivery of
that satisfies each of the requirements of an any records, documentation and data related to
origination agreement under the Rules. copies of items, copies of source documents or
records of authorization.
In addition to requiring specific provisions in their
agreements with the ODFI, the Rules also subject Section VI, Chapter 50 of these Guidelines
Third-Party Senders to a number of obligations: contains an expanded discussion of Third-
Party Senders and Third-Party Service
• 
Identification of Originators – The Rules Providers.
obligate each Third-Party Sender to provide
the ODFI with any information that the ODFI
considers to be reasonably necessary to identify
each Originator for which the ODFI transmits
entries. Upon the receipt of a request from the
ODFI for such information, the Third-Party
Sender must provide the requested data to the
SECTION V
ODFI within two banking days.

• 
Warranties of/Indemnifications by Third-
Standard Entry
Party Senders – Each Third-Party Sender
that authorizes an ODFI to transmit entries Class Codes
to a Receiver’s account warrants to the ODFI
that the Originator has agreed to assume the
responsibilities of an Originator, as required by
the NACHA Operating Rules. In any case in which
the Originator fails to perform its obligations as CHAPTER 36
an Originator under the Rules, the Third-Party
Acknowledgment Entries
Sender indemnifies the ODFI against any loss.
(ACK & ATX)
• Performance of ODFI Obligations – If a Third-
Party Sender performs any obligations of an
ODFI under the Rules, the Third-Party Sender Two Standard Entry Class Codes are available for
must also perform the requirements of an ODFI use by ACH participants that allow Originators to
under the Rules, and must warrant that it is request an acknowledgment from the RDFI that a
legally able to do so. These responsibilities corporate credit entry has been received and that
include conducting an annual audit of the Third- the RDFI will attempt to post the payment to the
Party Sender’s compliance with the NACHA Receiver’s account.
Operating Rules. The Rules do not relieve the
ODFI of any of its obligations when they are The ACK and ATX Standard Entry Class Codes
performed by a Third Party Sender. provide the platform for state and Federal

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG49
SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

government agencies and other corporate users noted that, in order for the Originator to receive
to utilize the ACH Network for acknowledgment the requested acknowledgment, both the ODFI and
purposes. the RDFI of the entry must support the appropriate
acknowledgment formats. Originators may wish to
An acknowledgment entry is a non-dollar consider whether they need to develop a process
transaction transmitted by the RDFI in response to identify and react to situations in which a
to a request for an acknowledgment contained requested acknowledgment entry is not received.
within the forward CCD or CTX credit entry. The
ACK format is used by the RDFI to acknowledge An RDFI which supports the ACH acknowledgment
the receipt of entries originated using the CCD process will transmit an ACK or ATX entry so that
format. The ATX format is used by the RDFI to it is made available to the ODFI no later than
acknowledge the receipt of entries originated the opening of business on the second banking
using the CTX format. day following the Settlement Date of the CCD or
CTX entry to which the acknowledgment relates.
Use of the ACH acknowledgment process is An ACK or ATX entry transmitted by the RDFI in
optional for all participants, enabling corporations response to a request for an acknowledgment may
and financial institutions to utilize and/or provide be accompanied by one optional Addenda Record.
ACH acknowledgment services based upon their The Addenda Record contains an 80-character
individual organizations’ business needs. Payment-Related Information field, within which
an ANSI ASC X12 REF (Reference) data segment
RESPONSIBILITIES OF ORIGINATORS may be entered which includes information about
the acknowledgment as agreed to by the trading
Since the ACH acknowledgment process is an optional
partners.
service for all ACH participants, Originators and
Receivers wishing to exchange acknowledgments
Refused Acknowledgment Entries
via the ACH Network will need to address the use
of acknowledgment entries in their trading partner In the event that an Originator receives an ACK
agreements. Originators should also be aware or ATX entry that is transmitted to it in error by
that the ODFI and RDFI involved in the payment the RDFI or that contains incorrect information,
process may, but are not required to, receive and the Originator may request its ODFI to transmit
process acknowledgment entries on behalf of a refused acknowledgment entry to the RDFI in
their corporate customers. As a result, Originators accordance with the requirements of the NACHA
choosing to utilize the acknowledgment process Operating Rules. A refused acknowledgment
should address the use of the acknowledgment entry (refused ACK or refused ATX) should be
process in their Originator-ODFI agreements. transmitted by the ODFI within fifteen days of the
Settlement Date of the misrouted or erroneous
Request for Acknowledgment acknowledgment entry.

An Originator may request that an acknowledgment

entry be transmitted by the RDFI in response to a
CCD or CTX credit entry by placing “AK” within
the Discretionary Data field of the CCD or CTX CHAPTER 37

entry for which the acknowledgment is desired. Accounts Receivable Entries

An RDFI that supports the acknowledgment
process will transmit an acknowledgment entry
(ARC)
with the Standard Entry Class Code “ACK” to
the ODFI in response to a CCD entry for which
An Accounts Receivable Entry (ARC) is a Single
an acknowledgment entry is requested. An
Entry Debit initiated by an Originator to the
acknowledgment entry with the Standard Entry
account of a Receiver based on an eligible source
Class Code “ATX” will be transmitted by the
document provided to the Originator by the
RDFI in response to a CTX entry for which an
Receiver (check writer) (1) via the U.S. mail or
acknowledgment entry is requested. It should be

OG50 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

delivery service, (2) at a dropbox location, or (3) in SOURCE DOCUMENTS

person for payment of a bill at a manned location.
The Originator can accept an eligible check as a
source document to initiate an ARC entry only if
The Rules governing ARC entries define specific
(1) it has been sent through the U.S. mail (or an
eligibility requirements and limits on the types
equivalent service, such as an overnight delivery
of source documents that may be converted.
service); (2) it has been delivered to a dropbox;
Originators are permitted to convert only checks
or (3) it has been presented by the Receiver in-
written for an amount of $25,000 or less. Further,
person for the payment of a bill at a manned
to enable Originators to readily identify business
location. (For a detailed list of eligibility criteria
checks that are ineligible for conversion and
for check conversion entries, refer to the Source
exclude those items from ACH conversion,
Document Eligibility Charts in Appendix E of these
ARC rules require Originators to exclude from
Guidelines, or to the definition of Eligible Source
conversion any check that contains an Auxiliary
Document within Article Eight of the Rules.)
On-Us Field within the MICR line.

OBLIGATIONS OF ORIGINATORS
INITIATING AN ARC ENTRY —
AN OVERVIEW Agreements With ODFIs
• The Originator provides the Receiver (the An Originator using the ACH Network to convert
check writer) with notice prior to receipt of the eligible checks received (1) through the U.S. mail
eligible source document, stating that a check (or via an equivalent delivery service), (2) at a
may be converted and collected electronically. dropbox location, or (3) in-person for the payment
For the in-person payment of a bill at a manned of a bill at a manned location, and collect them
bill payment location, the Originator must also using Accounts Receivable Entries should consider
provide the Receiver with a copy of the notice, modifications to its agreement with its ODFI to
or language that is substantially similar, at the address specific issues related to the origination
time of the transaction. of ARC entries. In addition to being bound to
the requirements of the NACHA Operating Rules
• Receiver (customer) either mails or delivers to through its ODFI/Originator agreement, an
an unmanned dropbox a check for a payment Originator and its ODFI should also address any
to the Originator, or presents a check to the processing obligations, timing, liabilities, etc.,
Originator in-person for the payment of a bill at that are unique to the ARC application. These
a manned location. modifications could, for example, address the
extent to which the Originator and ODFI share
• The Originator (usually a biller, such as a utility liability for the following warranties as they apply
company, financial institution, credit card issuer, to the origination of ARC entries:
internet or telecommunications company)
uses a check reading device to capture MICR • The amount of the entry, the routing number, the
information from the check (i.e., routing number, account number, and the check serial number
account number and serial number), which are in accordance with the source document;
is used by the Originator to generate a debit
entry to the Receiver’s account. The Originator • The Originator must retain a reproducible and
may not key enter MICR information from the legible copy of the front of the Receiver’s source
check, nor may the originator key enter MICR document for two years from the Settlement
information after the check reader has captured Date of the ARC entry. Upon receipt of an
the data, except as specifically noted later in this RDFI’s written request, the ODFI must provide
chapter. such copy to the RDFI within ten banking
days. Originators must be prepared to provide
• The amount of the entry is also entered from the such copies to their ODFIs for this purpose.
check. Originators may also choose, at their discretion,
to retain a copy of the back of the Receiver’s
source document.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG51
SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

• The source document used for an ARC entry “When you provide a check as payment,
must not be presented for payment unless the you authorize us to use information
ARC entry is returned by the RDFI. That is, to from your check to make a one-time
avoid “double dipping,” the check may not be electronic fund transfer from your
collected through the paper collection system account. In certain circumstances, such
unless the ACH debit is returned by the RDFI. as for technical or processing reasons,
In addition to the RDFI and ACH Operator, this we may process your payment as a
warranty runs to any other party that may be check transaction.”
liable on the source document.
An Originator may also choose to use wording
• The Originator must employ commercially other than the Regulation E safe harbor language
reasonable methods to securely store (1) all provided above, provided that it is substantially
source documents until destruction, and (2) all similar to the Regulation E safe harbor language.
banking information relating to ARC entries.
For purposes of Regulation E, electronic check
Authorization/Notification Requirements transactions are one-time transfers, which require
Originators are required to provide notice to notice to be provided and an authorization obtained
the Receiver, prior to the receipt of each source from the Receiver for each entry. As a result, the
document that will be used as the basis for the ARC notice discussed above must be provided to
origination of an ARC entry, that receipt of the the Receiver prior to the initiation of each ARC
Receiver’s check is deemed to be the Receiver’s entry. The Originator must also provide a copy of
authorization for an ACH debit entry to the the notice, or language that is substantially similar,
Receiver’s account, in accordance with the terms to the Receiver at the time of the transaction when
of the source document. The check is used solely the source document for the Entry is provided by
as a source document for capturing the Receiver’s the Receiver in-person for payment of a bill at a
routing number, account number, check serial manned location.
number, and dollar amount for the entry. The
provision of the notice by the Originator to the Originators must ensure that the required notice
Receiver and the receipt of the source document is clear and readily understandable, and must
together constitute authorization of the ARC provide it in a prominent and conspicuous manner.
entry. A notice in small print and buried in the middle
of unrelated information, for example, is not
The rules governing ARC incorporate Regulation considered to be in a prominent and conspicuous
E safe harbor language into the required notice, location. It is common practice for Originators to
requiring that the notice include the following, or provide the required notice by placing it on the
substantially similar, language: face of the bill (which billers may present to their
customers in paper or electronic form) or on the
“When you provide a check as back of the bill’s first page. Originators should
payment, you authorize us either to use consider using headings preceding the notice to
information from your check to make a draw attention to the information presented to
one-time electronic fund transfer from Receivers, or the use of indicators on the front of
your account or to process the payment the statement to direct them to complete language
as a check transaction.” on the reverse side. If the required notice is not
included on the bill, an Originator intending to
The following alternative safe harbor language is convert eligible checks to ARC Entries must ensure
also provided by Regulation E and may be used to that such notice is provided to the Receiver prior
comply with these notice requirements: to accepting the check as payment. An Originator
could, for example, accomplish this by posting
signage with the required language in a prominent

OG52 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

and conspicuous location at the manned bill Opting Out of Check Conversion
payment location and providing the check writer At their discretion, Originators of ARC entries may
with a take away copy of the notice. choose to allow Receivers to opt out of ARC check
conversion, although the NACHA Operating Rules
Notice on Coupon Books do not require them to do so. Originators that
In certain, limited circumstances, however, such as provide their customers with an opt-out option
where lenders provide coupon books to Receivers may establish their own reasonable policies and
(typically for mortgages, automobile loans, practices for enabling a Receiver to opt out of
personal loans, and other recurring loan payments), check conversion for a specific checking account.
Originators do not have the same opportunities
to provide notice as they do with in-person Requirements for MICR Capture
transactions or with mailed billing statements or During initial processing of ARC entries, Originators
invoices because the coupon books are provided must use a reading device to capture the Receiver’s
to the Receiver in advance and include coupons routing number, account number, and check serial
for several payments. Because a coupon book is number from the MICR line of the Receiver’s
designed so that a consumer must detach a coupon eligible source document. Although this data may
from the book and provide the coupon with each not be key entered during initial processing, key
payment, a separate notice with respect to check entry is permitted for subsequent correction of
conversion need not be printed on each payment errors related to MICR misreads, misencoding, or
coupon, provided that the notice is placed in a processing rejects.
conspicuous location on the coupon book (e.g.,
on the first page or inside the front cover) that the Although the Rules require an RDFI to accept an
consumer can retain. ACH transaction that bears information that was
accurately obtained from the on-us field of the
Notice When Multiple Payments or Multiple MICR line of a check, differences in banks’ MICR
Checks are Provided for One Bill lines may present Originators with challenges
In other circumstances, where multiple payments properly parsing the MICR line for accurate
may be remitted in response to one bill or invoice, formatting of an ARC entry. Originators may wish
such as when multiple checks are submitted within to consider the development of databases and the
a particular billing period related to one account, or use of other available MICR resources to facilitate
multiple checks are received from the Receiver or processing of ARC transactions.
another party with respect to a particular account,
it may be difficult for Originators to provide notice Collection of Return Fees
prior to the receipt of each individual check. ARC entries must be originated so that the amount
Under these circumstances, the provision of the of the entry, the routing number, the account
required notice to the Receiver listed on the billing number, and the check serial number accurately
account is sufficient for the conversion of all checks reflect the source document. No fees of any
provided in payment for the billing cycle or the type may be added to the amount of the source
invoice for which notice was provided, regardless document when it is transmitted as an ARC entry.
of whether the checks are received from the
Receiver or another party for that account. This An Originator desiring to use the ACH Network to
notice applies to all checks submitted as payment collect a Return Fee from a Receiver must originate
until the provision of notice on or with the next a separate Return Fee Entry using the appropriate
invoice or statement. Standard Entry Class Code and must follow all
rules governing the origination of Return Fee
Entries. For specific information on Return Fee
Entries, please refer to Chapter 54 in the Special
Topics section of these Guidelines.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG53
SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

Originators need to be aware that the requirements position of the Check Serial Number field, and
of the NACHA Operating Rules regarding the any unused spaces within the field must be
origination of Return Fee Entries are in addition to left blank.
any requirements defined by applicable state law
governing Return Fees. Originators are responsible Therefore, for check number 1234:
for determining what the applicable state laws are,
if any, for each of their check-accepting locations CORRECT 1234
that intend to, or may, use the ACH Network for
the collection of Return Fees. INCORRECT 0001234
000000000001234
Formatting Requirements CK# 001234
• Dollar Amount – ARC entries must be originated CK1234
for amounts of $25,000 or less.
1234 6532986002
• Company Name – Originators must ensure that CK1234 48832817
the name of the Originator (that is, the payee
of the source document) or the payee name Originators should be aware that the NACHA

indicated on the bill or invoice appears within Operating Rules require RDFIs to print the check
the Company Name Field of the Company/Batch serial number on both consumer and business
Header Record of the ARC entry. The contents Receivers’ bank statements.
of this field are provided to the Receiver for
descriptive purposes by the RDFI, and must be • Individual Name/Receiving Company Name
formatted in such a manner that the Receiver – The inclusion of the Receiver’s name within
can easily recognize the Originator of the the Individual Name/Receiving Company
payment (e.g., a trading as or doing business Name Field of the ARC Entry Detail Record is
as name, etc.). Originators should be aware optional, at the discretion of the Originator. If
that the Receiver looks for a familiar name to the Originator chooses to utilize this field, it
identify the transaction; if the Receiver does must include either (1) the Receiver’s name, or
not recognize the Company Name as presented (2) a reference number, identification number,
on his statement, the Receiver may instruct his or code that the merchant uses to identify a
RDFI to return the transaction as unauthorized. particular transaction or customer. (NOTE:
When a reference number, identification number,
• Check Serial Number – The check serial number or code is used to identify the transaction or
of the eligible source document to which the customer, it should be uniquely related to the
ARC entry relates must be placed within the Receiver or transaction. A generic description is
Check Serial Number Field of the ARC Entry not an acceptable means to identify the Receiver
Detail Record. or the transaction.)

The NACHA Operating Rules permit Originators Reinitiation of ARC Entries

to place only the check serial number within ARC entries that have been returned for insufficient
the Check Serial Number Field of the ARC or uncollected funds may be reinitiated up to two
Entry Detail Record. That is, the word “check,” times following the return of the original entry,
abbreviations such as “ck” or “chk,” or other provided such reinitiations are transmitted by the
merchant codes must not be included within the Originator (or its ODFI on the Originator’s behalf)
field. Because the Check Serial Number Field within 180 days of the settlement date of the
is defined as an alphanumeric one, the NACHA original entry.
Operating Rules require information within this
field to be left justified and space filled. The serial For ARC entries returned for any other reason, the
number of the check must begin in the leftmost Originator must first remedy the reason for the
return before reinitiating the transaction within
the 180-day time period discussed above.

OG54 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

Retention/Secure Storage of Source When choosing a commercially reasonable

Documents and Payment Information method for secure data storage, Originators should
Each Originator of ARC entries must retain a consider the following guidance provided by the
reproducible image or other copy of the front of Federal Trade Commission for complying with
the Receiver’s source document for a period of the Safeguards Rule, which implements security
two years from the Settlement Date of the entry. measures within the Gramm-Leach-Bliley Act.
Originators may also choose, at their discretion, to
retain a copy of the back of the Receiver’s source • know where sensitive information is stored and
document. The Originator must be prepared to that it is stored securely;
provide such a copy to the ODFI, as the ODFI is
required to send a copy of the front of the source • ensure that only authorized personnel have
document to the RDFI within 10 banking days of access to sensitive data;
receipt of the RDFI’s written request, provided that
the RDFI’s request is received within two years of • ensure that storage areas are protected against
the Settlement Date of the entry. destruction or damage from physical hazards
such as fire or floods;
The Rules do not explicitly require an Originator
to destroy the source document to which the ARC • store records in a room or cabinet that is locked
entry relates. Although an Originator may use when unattended;
its discretion in determining how long to retain
the original source document, Originators are • when information is stored on a server or other
encouraged to establish policies and procedures computer, ensure that the computer is accessible
to destroy ARC source documents as soon as is only with a strong password and that it is kept
reasonable to protect against the risk of fraud in a physically secure area;
or erroneous entry of the check into the check
processing system. Until such time that the source • avoid storing sensitive information on an
document is destroyed by the Originator, it must electronic device with an Internet connection;
be securely stored using commercially reasonable
• maintain secure backup records and keep
methods.
archived data secure by storing it off-line and in
The Rules also require Originators to use a physically secure area;
commercially reasonable methods to securely
• maintain a careful and accurate inventory of the
store all banking information related to the ARC
company’s electronic devices and of the storage
transaction. Banking information includes, but
location of any other sensitive information.
is not limited to, an entry, entry data, a routing
number, an account number, PINs and other
When destroying ARC source documents or
identification symbols, etc.
other banking information, Originators should
establish reasonable measures for destroying such
For a discussion on the concept of commercially
information that may include:
reasonable standards, please refer Chapter 4 of
these Guidelines.
• burning, pulverizing, or shredding papers that
contain such information so that the information
Although the NACHA Operating Rules do not
can not be read or reconstructed;
otherwise address data security with respect to the
secure storage of banking and related information,
• using outside disposal company that has been
such requirements may be governed by state or
certified by a recognized industry group;
Federal laws and regulations. Originators should
ensure that they are familiar with any such laws
• destroying and/or erasing data when disposing
when determining the commercial reasonableness
of computers, disks, CDs, magnetic tapes, hard
of their storage methods.
drives, laptops, PDAs, cell phones, or any

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG55
SECTION V – Standard Entry Class Codes
C H A P T E R 3 7   A C C O U N T S R E C E I VA B L E E N T R I E S

other electronic media or hardware containing 1. An RDFI that determines that an ARC entry was
banking information. based on an improper source document, or that
the entry and the source document were both
Return of Accounts Receivable Entries presented for payment, may return the entry
ARC entries are governed by the same Return using Return Reason Code, R39 (Improper
Reasons and Return Reason Codes as other ACH Source Document/Source Document Presented
debit entries (a complete listing of Return Reason for Payment). Entries returned using this return
Codes can be found within Appendix Four of the reason code must be received by the RDFI’s ACH
NACHA Operating Rules). In addition, some special Operator’s deposit deadline for the return entry
circumstances can apply, as described below. to be made available to the ODFI no later than
opening of business on the second banking day
Return by ACH Operator following the Settlement Date of the original
entry. No written statement of unauthorized
ARC entries are limited to dollar amounts of
debit is required for this code.
$25,000 or less. Any ARC entry originated in an
amount greater than $25,000 will be returned by
2. 
When the Receiver, rather than the RDFI, as
the ACH Operator.
discussed above, determines that the source
document to which an ARC entry relates was
Return by RDFI improper or that the entry and the source
Timing of Returns document were both presented for payment,
Most ARC entries need to be returned by the RDFI the RDFI may return the entry so that it is made
so that the return entry is made available to the available to the ODFI by the opening of business
ODFI no later than the opening of business on the on the banking day following the sixtieth
second banking day following the Settlement Date calendar day following the Settlement Date of
of the ARC entry. the original entry using Return Reason Code
R10 or R37, respectively. A written statement
In the following circumstances, an RDFI may also of unauthorized debit is required when using
return an ARC entry so that it is made available to either of these return reason codes.
the ODFI by opening of business on the banking
day following the sixtieth calendar day following Stop Payments
the Settlement Date of the original entry for the As with other Single-Entry ACH transactions, a
following reasons: 1) no notice was provided to the Receiver desiring to place a stop payment order on
Receiver that the check was going to be converted an ARC entry may do so, provided that he notifies
to an ACH debit, 2) improper source document, 3) his RDFI in such a time and manner that allows the
the source document was presented for payment RDFI a reasonable opportunity to act on the stop
as a check through the check collection system, or payment order prior to acting on the debit entry.
4) the ARC transaction was initiated in an amount ARC entries returned by the RDFI as payment
other than that indicated on the source document. stopped will bear the Return Reason Code R08 and
In these circumstances, the RDFI requires the will be made available to the ODFI by opening of
Receiver to sign or similarly authenticate a written business on the second banking day following the
statement of unauthorized debit prior to being re- settlement date of the ARC entry.
credited for the transaction.
Originators should note that the RDFI may also
Returns for Improper Source Documents or return an ARC entry if the Receiver places a stop
When Both ARC Entry and Source Document payment on the source document (i.e., in the
Have Been Presented check stop payment system) instead of the ACH
With respect to ARC entries based on improper stop payment system. In this situation, the RDFI
source documents or where both the ARC entry must transmit the return using Return Reason
and the source document have been presented Code R38 (Stop Payment on Source Document)
for payment, an RDFI may return such entries in so that it is made available to the ODFI by the
either of two ways: opening of business on the banking day following

OG56 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

the sixtieth calendar day following the Settlement a take-away copy of the notice language at the
Date of the original entry. This time frame allows time of the transaction.
a “safety net” for RDFIs that have not linked their
check and ACH systems to check for stop payment • The customer presents a check for payment.
orders for this application. A written statement of The Originator retains the check for subsequent
unauthorized debit is not required for this return processing in the back office.
reason.
• In the back office, the Originator determines
whether the check is eligible for conversion.
If so, the Originator uses a reading device to
capture MICR information from the check (i.e.,
CHAPTER 38
routing number, account number, and serial
Back Office Conversion Entries number), and generates a debit entry to the
(BOC) Receiver’s account.

SOURCE DOCUMENTS
The Back Office Conversion (BOC) Entry application The Originator may use an eligible check as a
enables Originators to convert, during back office source document for the initiation of a BOC entry
processing, checks presented by the Receiver for if it has been provided to the Originator at either
payments made at either the point of purchase or the point of purchase or a manned bill payment
a manned bill payment location. BOC entries are location. For a detailed list of eligibility criteria
Single-Entry debits and may only be used for non- for check conversion entries, refer to the Source
recurring, in-person payments where there is no Document Eligibility Charts within Appendix E of
standing authorization for the origination of ACH these Guidelines, or to the definition of Eligible
debits to the Receiver’s account. Source Document within Article Eight of the Rules.

The rules governing BOC entries define specific

OBLIGATIONS OF ORIGINATORS
eligibility requirements and limits on types of source
documents that may be converted. Originators Agreements with ODFIs
are permitted to convert only those checks in An Originator using the ACH Network to convert
an amount of $25,000 or less. Further, to enable eligible checks received at the point of purchase
Originators to readily identify business checks that or manned bill payment location and collect them
are ineligible for conversion and exclude those as Back Office Conversion Entries should consider
items from ACH conversion, BOC rules require modifications to its agreement with its ODFI to
Originators to exclude from conversion any check address specific issues related to the origination
that contains an Auxiliary On-Us Field within the of BOC entries. In addition to being bound to
MICR line. the requirements of the NACHA Operating Rules
through its ODFI/Originator agreement, an
INITIATING A BOC ENTRY — Originator and its ODFI should also address any
AN OVERVIEW processing obligations, timing, liabilities, etc.,
that are unique to the BOC application. These
• Prior to accepting a check at the point of
modifications could, for example, address the
purchase or at a manned bill payment location,
extent to which the Originator and ODFI share
the Originator provides the check writer
liability for the following warranties as they apply
(Receiver) with notice stating that his check may
to the origination of BOC entries:
be converted and collected electronically. One
way an Originator may meet this requirement
• The ODFI has, prior to originating BOC entries,
is by posting the required notice in a clear and
employed commercially reasonable procedures
conspicuous location at the point of purchase/
to verify the identity of each Originator or Third-
manned bill payment location; however, the
Party Sender initiating such entries.
Originator must also provide the Receiver with

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG57
SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

• The ODFI has, prior to originating BOC entries, the BOC entry is returned by the RDFI. That is,
established procedures to maintain the following to avoid “double dipping,” the check may not be
information with respect to each Originator of collected through the paper collection system
such entries: unless the ACH debit is returned by the RDFI.
In addition to the RDFI and ACH Operator, this
– company name; warranty runs to any other party that may be
– address; liable on the source document.
– telephone number;
• The Originator must employ commercially
– contact person; reasonable methods to securely store (1) all
– taxpayer identification number; and source documents until destruction, and (2) all
– a description of the nature of the business of banking information relating to BOC entries.
each Originator.
Authorization/Notification Requirements
• The ODFI has established practices and Originators are required to provide notice to
procedures to provide the RDFI with information the Receiver, prior to the receipt of each eligible
identifying the Originator of BOC entries within source document that is used as the basis for the
two banking days of receipt of the RDFI’s origination of a BOC entry, that receipt of the
written request for such information, provided Receiver’s check is deemed to be the Receiver’s
the RDFI’s written request is received within authorization for an ACH debit entry to the
two years of the Settlement Date of the original Receiver’s account, in accordance with the terms
entry. of the eligible source document. The check is
used solely as the eligible source document for
• The Originator has employed commercially capturing the Receiver’s routing number, account
reasonable procedures to verify the identity of number, check serial number, and dollar amount
each Receiver of BOC entries. for the entry. The provision of the notice by the
Originator to the Receiver and the receipt of the
• Each Originator of BOC entries maintains a eligible source document together constitute
working telephone number that is answered authorization of the BOC entry.
during the Originator’s normal business hours for
Receiver inquiries regarding BOC transactions. The rules governing BOC incorporate Regulation
This telephone number must also be displayed E safe harbor language into the required notice,
on the required notice for BOC entries. requiring that the notice include the following, or
substantially similar, language:
• The amount of the entry, the routing number, the
account number, and the check serial number “When you provide a check as
are in accordance with the source document; payment, you authorize us either to use
information from your check to make a
• The Originator has retained a reproducible and one-time electronic fund transfer from
legible copy of the front of the Receiver’s source your account or to process the payment
document for two years from the Settlement as a check transaction. For inquiries,
Date of the BOC entry. please call <retailer phone number>.”


(Upon receipt of an RDFI’s written request,
the ODFI must provide such copy to the RDFI
within ten banking days. Originators must be
prepared to provide copies to their ODFIs for
this purpose.)

• The source document to which the BOC entry

relates must not be presented for payment unless

OG58 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

The requirement to include a retailer’s telephone In cases where an electronic device is used, the
number above is not required as part of the notice can be displayed on the screen for the
Regulation E safe harbor language but is a Receiver to read prior to providing the eligible
requirement of the NACHA Operating Rules with source document for conversion. Alternatively,
respect to the notice obligation. the notice can be provided on an invoice or
billing statement that the Receiver can read prior
Regulation E also provides alternative safe harbor to providing the eligible source document for
notice language, below, that Originators may conversion. Originators should understand that
choose to use for electronic check conversion. the term “provide” is intended to mean that the
Originators using this alternative language also Originator has utilized a medium (e.g., written
need to include the retailer’s telephone number as document, tablet, computer screen, or other
required by the Rules. method) that allows the Receiver to read the notice
prior to the Originator’s receipt of the eligible
“When you provide a check as payment, source document.
you authorize us to use information
from your check to make a one-time The Originator must also provide the Receiver
electronic fund transfer from your with a take-away copy of the notice language (or
account. In certain circumstances, such language that is substantially similar) at the time
as for technical or processing reasons, of the transaction.
we may process your payment as a
check transaction.” This notice as authorization is the minimum
standard for compliance with the authorization
Originators are not required to use the safe harbor requirements for BOC entries. An Originator may
language discussed above. The actual wording of also choose, at its discretion, to obtain a signed,
the notice may be determined at the discretion written authorization for a BOC entry, but it is
of the Originator, provided that it is substantially still required to comply with all requirements for
similar to the safe harbor language and includes notice to be in compliance with Regulation E.
the retailer’s telephone number.
Opting Out of Check Conversion
For purposes of Regulation E, electronic check At their discretion, Originators may allow Receivers
transactions are one-time transfers, which require to opt out of BOC check conversion, although the
notice to be provided and an authorization NACHA Operating Rules do not require them to
obtained from the Receiver for each entry. As a do so. Originators that offer an opt-out option to
result, an Originator must provide the Receiver their customers should establish procedures under
with the required notice discussed above prior which a Receiver may notify the Originator, at the
to the initiation of each BOC entry. One way point of purchase or manned bill payment location,
an Originator may meet this requirement is by that a particular check does not authorize an ACH
posting the notice (which must be clear and readily debit entry to the Receiver’s account.
understandable) in a prominent and conspicuous
location at the point of purchase/manned bill Requirements for MICR Capture
payment location. A notice in small print and
During initial processing of BOC entries, Originators
buried in the middle of unrelated information, for
must use a MICR reading device to capture the
example, is not considered to be in a prominent
Receiver’s routing number, account number,
and conspicuous location. Originators should
and check serial number from the MICR line of
consider using headings preceding the notice to
the Receiver’s check (eligible source document).
draw attention to the information presented to the
Although this data may not be key entered during
Receiver. Notices provided on signage should not
initial processing, key entry is permitted, for
be obscured by other information or signs that
subsequent correction of errors related to MICR
may also be located at the point of purchase or
misreads, misencoding, or processing rejects.
manned bill payment location.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG59
SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

etc. (For more information on the concept of

Although the Rules require an RDFI to accept an commercially reasonable standards, please refer to
ACH transaction that bears information that was Chapter 4 of these Guidelines.)
accurately obtained from the on-us field of the MICR
line of a check, differences in financial institutions’ Originators should be aware that if the source
MICR lines may present Originators with challenges document is fraudulent, the BOC entry upon which
in being able to properly parse the MICR line for it is based is likely to be returned as unauthorized,
accurate formatting of a BOC entry. Originators no account found, other reasons, just as the source
may wish to consider developing databases and document, if processed as a check, would likely to
using other available MICR resources to facilitate be returned.
processing of BOC transactions.
RETAILER TELEPHONE NUMBER
COLLECTION OF RETURN FEES
Originators are required to establish and maintain a
BOC entries must be originated so that the amount working telephone number for Receiver questions
of the entry, the routing number, the account or inquiries regarding BOC entries. The person
number, and the check serial number accurately answering this telephone number must be capable
reflect the source document. No fees of any of supporting and responding to questions about
type may be added to the amount of the source specific BOC entries to a Receiver’s account and
document when it is transmitted as a BOC entry. not limited to the provision of general information
about the Back Office Conversion application.
An Originator desiring to use the ACH Network
to collect a Return Fee from a Receiver must
RETENTION/SECURE STORAGE OF
originate a separate Return Fee Entry using the
appropriate Standard Entry Class Code and must
SOURCE DOCUMENTS AND PAYMENT
follow all rules governing the origination of Return INFORMATION
Fee Entries. For specific information on Return Fee Each Originator of BOC entries is required to
Entries, please refer to Chapter 54 in the Special retain a reproducible, legible image or other copy
Topics section of these Guidelines. of the front of the Receiver’s source document for
a period of two years from the Settlement Date of
Originators need to be aware that the requirements the entry. Originators may also choose, at their
of the NACHA Operating Rules regarding the discretion, to retain a copy of the back of the
origination of Return Fee Entries are in addition to Receiver’s source document. The Originator must
any requirements defined by applicable state law be prepared to provide such a copy to the ODFI,
governing Return Fees. Originators are responsible as the ODFI is required to send a copy of the front
for determining what the applicable state laws are, of the source document to the RDFI within 10
if any, for each of their check-accepting locations banking days of receipt of a written request for
that intend to, or may, use the ACH Network for such copy by the RDFI, provided that the RDFI’s
the collection of Return Fees. written request is received by the ODFI within two
years of the settlement date of the BOC entry.
VERIFICATION OF RECEIVER’S
IDENTITY The Rules do not explicitly require an Originator
to destroy the source document to which the BOC
To minimize the potential for Receiver fraud, the
entry relates. Although an Originator may use
Originator must use a commercially reasonable
its discretion in determining how long to retain
procedure to verify the Receiver’s identity
the original source document, Originators are
prior to originating a BOC entry. Examples of
encouraged to establish policies and procedures
commercially reasonable means of verifying the
to destroy BOC source documents as soon as is
Receiver’s identity include, but are not limited to,
reasonable to protect against the risk of fraud
the examination of a photo identification (e.g.,
or erroneous entry of the check into the check
driver’s license, passport, other photo ID), use of a
processing system. Until such time that the source
retailer preferred card, check verification services,

OG60 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

document is destroyed by the Originator, it must • maintain a careful inventory of the company’s
be securely stored using commercially reasonable electronic devices and of the storage location of
methods. any other sensitive information.

The Rules also require Originators to use When destroying BOC source documents or
commercially reasonable methods to securely other banking information, Originators should
store all banking information related to the BOC establish reasonable measures for destroying such
transaction. Banking information includes, but information that may include:
is not limited to, an entry, entry data, a routing
number, an account number, PINs and other • burning, pulverizing, or shredding papers that
identification symbols, etc. contain such information so that the information
cannot be read or reconstructed;
Although the NACHA Operating Rules do not
otherwise address data security with respect to the • the use of an outside disposal company that has
secure storage of banking and related information, been certified by a recognized industry group;
such requirements may be governed by state or
Federal laws and regulations. Originators should • the destruction and/or erasure of data when
be familiar with any such laws when determining disposing of computers, disks, CDs, magnetic
the commercial reasonableness of their storage tapes, hard drives, laptops, smartphones,
methods. cell phones, or any other electronic media or
hardware containing banking information.
When choosing a commercially reasonable
method for secure data storage, Originators should FORMATTING REQUIREMENTS
consider the following guidance provided by the
• Dollar Amount – BOC entries must be originated
Federal Trade Commission for complying with
for amounts of $25,000 or less.
the Safeguards Rule, which implements security
measures within the Gramm-Leach-Bliley Act. • Company Name – Originators must ensure that
the name of the Originator (that is, the payee
• know where sensitive information is stored and
of the source document) or the payee name
that it is stored securely;
indicated on the bill or invoice appears within
the Company Name Field of the Company/
• ensure that only authorized personnel have
Batch Header Record of the BOC entry. The
access to sensitive data;
contents of this field are provided to the
Receiver for descriptive purposes by the RDFI,
• ensure that storage areas are protected against
and must be formatted in such a manner that
destruction or damage from physical hazards
enables the Receiver to easily recognize the
such as fire or floods;
Originator (e.g., a trading as or doing business
as name, etc.). Originators should be aware
• store records in a room or cabinet that is locked
that the Receiver looks for a familiar name to
when unattended;
identify the transaction; if the Receiver does
not recognize the Company Name as presented
• when information is stored on a server or other
on his statement, the Receiver may instruct his
computer, ensure that the computer is accessible
RDFI to return the transaction as unauthorized.
only with a strong password and that it is kept
in a physically-secure area;
• Check Serial Number – The check serial number
of the source document to which the BOC entry
• avoid storing sensitive information on an
relates must be placed within the Check Serial
electronic device with an Internet connection;
Number Field of the BOC Entry Detail Record.
• maintain secure backup records and keep
The Rules permit Originators to place only the
archived data secure by storing it off-line and in
check serial number within the Check Serial
a physically-secure area;

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG61
SECTION V – Standard Entry Class Codes
CHAPTER 38  BACK OFFICE CONVERSION ENTRIES

Number Field of the BOC Entry Detail Record. by the Originator (or its ODFI on the Originator’s
That is, the word “check,” abbreviations such behalf) within 180 days of the settlement date of
as “ck” or “chk,” or other merchant codes must the original entry.
not be included within the field. Because the
Check Serial Number Field is defined as an For BOC entries returned for any other reason, the
alphanumeric one, the Rules require information Originator must first remedy the reason for the
within this field to be left justified and space return before reinitiating the entry within the 180-
filled. The serial number of the check must day time period discussed above.
begin in the leftmost position of the Check Serial
Number field, and any unused spaces within the RETURN OF BOC ENTRIES
field must be left blank.
BOC entries are governed by the same Return
Reasons and Return Reason Codes as other ACH
Therefore, for check 1234:
debit entries (a complete listing of Return Reason
Codes can be found within Appendix Four of the
CORRECT 1234
NACHA Operating Rules). In addition, some special
INCORRECT 0001234 circumstances can apply, as described below.
000000000001234
Return by ACH Operator
CK# 001234 BOC entries are limited to dollar amounts of
CK1234 $25,000 or less. Any BOC entry originated in an
1234 6532986002 amount greater than $25,000 will be returned by
CK1234 48832817 the ACH Operator.

Originators should be aware that the Rules

 Return by RDFI
require RDFIs to print the check serial number Most BOC entries need to be returned by the RDFI
on the Receiver’s bank statement for both so that the return entry is made available to the
consumer and business Receivers. ODFI no later than the opening of business on the
second banking day following the Settlement Date
• Individual Name/Receiving Company Name of the BOC entry.
– The inclusion of the Receiver’s name within
the Individual Name/Receiving Company In the following circumstances, an RDFI may also
Name Field of the BOC Entry Detail Record is return a BOC entry so that it is made available to
optional at the discretion of the Originator. If the ODFI by opening of business on the banking
the Originator chooses to utilize this field, it day following the sixtieth calendar day following
must include either (1) the Receiver’s name, or the Settlement Date of the original entry for the
(2) a reference number, identification number, following reasons: 1) no notice was provided to the
or code that the merchant uses to identify a Receiver that the check was going to be converted
particular transaction or customer. (NOTE: to an ACH debit, 2) improper source document, 3)
When a reference number, identification number, the source document was presented for payment
or code is used to identify the transaction or as a check through the check collection system, or
customer, it should be uniquely related to the 4) the BOC transaction was initiated in an amount
Receiver or transaction. A generic description is other than that indicated on the source document.
not an acceptable means to identify the Receiver In these five circumstances, the RDFI requires the
or the transaction.) Receiver to sign or similarly authenticate a written
statement of unauthorized debit prior to being re-
REINITIATION OF BOC ENTRIES credited for the transaction.
BOC entries that have been returned for insufficient
or uncollected funds may be reinitiated up to two
times following the return of the original entry,
provided that such reinitiations are transmitted

OG62 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

Returns for Improper Source Documents or Originators should note that the RDFI may also
When Both BOC Entry and Source Document return a BOC entry if the Receiver places a stop
Have Been Presented payment on the source document (i.e., in the
With respect to BOC entries based on improper check stop payment system) instead of the ACH
source documents or where both the BOC entry stop payment system. In this situation, the RDFI
and the source document have been presented must transmit the return using Return Reason
for payment, an RDFI may return such entries in Code R38 (Stop Payment on Source Document)
either of two ways: so that it is made available to the ODFI by the
opening of business on the banking day following
1. An RDFI that determines that a BOC entry was the sixtieth calendar day following the Settlement
based on an improper source document, or that Date of the original entry. This time frame allows
the entry and the source document were both a “safety net” for RDFIs that have not linked their
presented for payment, may return the entry check and ACH systems to check for stop payment
using Return Reason Code, R39 (Improper orders for this application. A written statement of
Source Document/Source Document Presented unauthorized debit is not required for this return
for Payment). Entries returned using this return reason.
reason code must be received by the RDFI’s ACH
Operator’s deposit deadline for the return entry
to be made available to the ODFI no later than
opening of business on the second banking day CHAPTER 39
following the Settlement Date of the original
entry. No written statement of unauthorized Corporate Credit or Debit and
debit is required for this code. Corporate Trade Exchange
2. 
When the Receiver, rather than the RDFI, as
Entries (CCD & CTX)
discussed above, determines that the source
document to which a BOC entry relates was
Corporate Credit or Debit (CCD) and Corporate
improper or that the entry and the source
Trade Exchange (CTX) Entries are debit or credit
document were both presented for payment,
entries used to facilitate business-to-business
the RDFI may return the entry so that it is made
(B2B) ACH payments. Although these ACH options
available to the ODFI by the opening of business
move money between business accounts in the
on the banking day following the sixtieth
same way, they are distinguished by the ability of
calendar day following the Settlement Date of
the Originator and Receiver to exchange various
the original entry using Return Reason Code
amounts of remittance information.
R10 or R37, respectively. A written statement of
unauthorized debit is required when using this • Corporate Credit or Debit (CCD) – The CCD
return reason code. application can be either a buyer-initiated or
seller-initiated transaction used to move funds
Stop Payments between the buyer’s and seller’s financial
As with other Single-Entry ACH transactions, a institution accounts. It is also used by companies
Receiver desiring to place a stop payment order on to move funds from outlying depository locations
a BOC entry may do so, provided that he notifies to a central bank account. This format may be
his RDFI in such a time and manner that allows the used as a stand-alone payment instruction for
RDFI a reasonable opportunity to act on the stop funds transfer, with no remittance detail included.
payment order prior to acting on the debit entry. Companies use the CCD format when there is
BOC entries returned by the RDFI as payment no need to exchange remittance information,
stopped will bear the Return Reason Code R08 and such as paying a single invoice.
will be made available to the ODFI by opening of
business on the second banking day following the 
Companies that need to transmit remittance
settlement date of the BOC entry. data with the CCD entry may add an addenda
record to carry the payment related information.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG63
SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

The addenda record carries 80 characters of that the biller uses to post the payment.
payment related information, which must be When remittance data needs to accompany
formatted using ANSI ASC X12 data segments a payment, the type of remittance data, along
or a NACHA-endorsed banking convention. The with the appropriate format (in accordance
addenda record may also be used to reference a with the Rules), is specified by the seller and
separate transmission of remittance information communicated to the buyer in advance of the
that flows outside of the ACH Network. The transaction.
CCD plus addenda (also known as a CCD+
entry) is typically used to pay a single invoice • Lower Payment and Remittance Processing Costs:
that is identified in the addenda record. It may The initiation of payments and processing of data
also be used for multiple invoices, providing a electronically removes many of the personnel
reassociation reference number for the source expenses required to handle paper remittances
of the remittance data. (i.e., salaries and overtime staffing during peak
periods), as well as the costs associated with
• Corporate Trade Exchange (CTX) – The paper storage and handling, such as opening
CTX application is also a buyer-initiated or envelopes, manually crediting the account, and
seller-initiated transaction used to move funds depositing payments.
between the buyer’s and seller’s financial
institution accounts. The CTX format supports • Improved Data Accuracy: The ability to carry
the transfer of extensive addenda records - up data and dollars together eliminates misrouted
to a maximum of 9,999 records each carrying remittances (there is an audit trail for all ACH
80 characters of payment related data - along transactions) and delays from bill stubs received
with the transfer of the payment. Remittance without a check, or checks received without a
information within CTX addenda records must bill stub. In addition, many ACH processors
be formatted as either a syntactically correct have integrated sophisticated methods to
ANSI ASC X12 transaction set or as a payment verify account numbers, further reducing the
related UN/EDIFACT transaction. The CTX possibility of errors.
format is typically used to pay multiple invoices
that are listed in the addenda records, although • Accelerated Cash Flow: The receipt of ACH
it may be used for a single invoice. payments makes cash flow and forecasting more
predictable, eliminates receiving checks by mail
LEGAL FRAMEWORK and reduces clearing float. For customers that
initiate credit payments, funds are immediately
In addition to the applicable NACHA Operating
available to the biller.
Rules, wholesale credit transactions transmitted
as CCD or CTX entries are governed by Article • Flexibility: The ACH Network allows both credit
4A of the Uniform Commercial Code. As they and debit payment options, and can be used in
are not consumer entries, they are not subject to any bill payment receivables channel. An ACH
Regulation E. solution is also widely available, and scalable,
allowing for adoption by both smaller and larger
BUSINESS-TO-BUSINESS PAYMENTS businesses and customers.
The ACH offers a number of special features
for business payments. By using ACH CASH CONCENTRATION AND
electronic payments for accounts payable and DISBURSEMENT
accounts receivable functions, businesses can
Cash concentration and disbursement are cash
realize significant cost-savings and processing
management techniques used by companies with
efficiencies.
remote locations to effectively manage funds.
Cash concentration consolidates all available funds
• Data and Dollars Together: The ACH Network
in a single account. Disbursement is controlled so
can carry both payment and remittance data.
The remittance data provides information

OG64 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

that cash can be fully invested during the day and ACH payment, it is possible that the seller will not
funding requirements for checks can be met. Cash be able to post the payment correctly, meaning
concentration and disbursement help improve the the buyer’s account will not be properly credited.
flow of cash, reduce excess balances and increase The seller may, therefore, only allow the buyer to
interest earned. The ACH Network provides originate a credit ACH payment once the buyer
companies with a quick and cost-efficient means agrees to the remittance requirements. As above,
for cash concentration. the terms of the agreement would be dictated by
the trading partner agreement.
OBLIGATIONS OF ORIGINATORS
Sellers and buyers should discuss special payment
Agreement with ODFI requirements prior to conducting business. The
An Originator using CCD/CTX entries should range of payment terms and conditions should be
consider modifying its agreement with its ODFI to covered in their trading partner agreement.
address specific issues related to the origination
of these entries. In addition to being bound The agreement will also specify the manner in
to the requirements of the NACHA Operating which dispute resolution will be handled.
Rules through its ODFI/Originator agreement,
the agreement should address any formatting RETURN OF CCD/CTX ENTRIES
requirements, processing obligations, warehousing,
timing, etc. that are unique to CCD/CTX entries. CCD and CTX entries are governed by the same
return reasons and Return Reason Codes as other
ACH debit entries. Most CCD/CTX entries need to
Agreement with Receiver
be returned by the RDFI so that the return entry
With business-to-business payments, ACH is made available to the ODFI no later than the
transactions originated by a buyer are credit opening of business on the second banking day
transactions because the buyer (the party that owes following the Settlement Date of the CCD/CTX
funds) “pushes” funds to the seller’s (party that is entry.
owed the payment) account. ACH transactions
originated by a seller are debit transactions because If an RDFI receives written notification from a
the seller “pulls” funds from the buyer’s account. Receiver after the time for return has expired that
a CCD or CTX debit entry to the Receiver’s account
As with all ACH transactions, the Originator of was not authorized by the Receiver, the RDFI may
a CCD or CTX entry must receive the Receiver’s transmit a permissible return entry to the ODFI,
authorization to debit or credit the Receiver’s provided that the ODFI has agreed, either verbally
account. The NACHA Operating Rules do not or in writing, to accept the late return entry. Such
require the CCD/CTX authorization to be in a a return must be transmitted using Return Reason
specific form. However, the rules require the Code R31 (Permissible Return Entry).
Originator and Receiver to have an agreement
that binds the Receiver to the Rules. This trading At times, Originators may erroneously transmit ACH
partner agreement should contain the authorization entries that are formatted using an incorrect SEC
requirements and procedures as determined by the Code. This is in violation of the NACHA Operating
parties; the companies negotiate the terms. Rules. The Rules allow the RDFI to rely on the
ODFI’s warranty that the SEC Code included in the
In some instances a seller may have specialized entry is proper and obligates the RDFI to use the
data remittance requirements for an electronic return rules and time frames associated with that
credit payment (e.g., specific data elements and particular SEC Code.
formats) and/or may require that remittance be
sent through a specific channel (e.g., the ACH, or a However, for an unauthorized debit to a consumer
private remittance network — sometimes referred account that bears a corporate SEC Code (i.e., CCD
to as a value-added network). If the buyer is unable or CTX), the RDFI may be unable to meet the time
to meet the exact specifications for making a credit frame for return because the return time frame

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG65
SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

for corporate entries may have lapsed before the CORPORATE ACH PAYMENT
consumer can receive his statement and notify his TRANSACTION FLOW
RDFI about the unauthorized debit to his account.
In order to enable the RDFI to treat all unauthorized Buyer-Initiated Payments:
debits to consumer accounts in a consistent manner, Credit Model – Data and Dollars Together
regardless of SEC Code, the NACHA Operating The process flow for a buyer-initiated payment
Rules define a specific Return Reason Code R05 when remittance data is included with the payment
(Unauthorized Debit to Consumer Account Using (data and dollars together) is shown in Figure 39-1.
Corporate SEC Code) that the RDFI may use to
return unauthorized entries to a consumer account Payment Initiation
that bear a corporate SEC Code. Returns bearing 1. 
The buyer and the seller may enter into a
Return Reason Code R05 must be transmitted by trading partner agreement that establishes
the RDFI in such time and manner that the return authorization for ACH payment. The seller
is made available to the ODFI no later than the must provide the buyer with the bank routing
opening of business on the banking day following number of its financial institution and depository
the sixtieth calendar day following the Settlement account number or electronic lockbox account
Date of the original entry. number. This information is used to route
the ACH payment to the seller. Typically, the
A complete listing of Return Reason Codes can seller notifies the buyer about the desired data
be found within Appendix Four of the NACHA requirements and ACH format in the trading
Operating Rules. partner agreement.

FIGURE 39-1

OG66 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

2. The buyer, who is the Originator of the ACH Remittance

transaction, initiates an ACH credit through its 6. 
Remittance data, which is generated by the
financial institution, the ODFI. The buyer uses buyer in step 2 above, is provided by the RDFI
the payment and remittance format agreed to to the seller in the format agreed to by the
with the seller. seller and the RDFI in their contract. Remittance
data, accommodated in either the CCD or CTX
3. The ODFI formats the payment and remittance addenda records, contains the information
data per the Originator’s instructions, or uses necessary for the seller to accurately update its
formatted data provided by the Originator, and accounts receivables.
sends the ACH transaction to the ACH Operator
in a batch transmission one to two days prior to 7. The payment is posted to the seller’s accounts
the desired Settlement Date. receivable system.

4. 
The ACH Operator sorts and batches ACH Buyer-Initiated Payments:
transactions for the appropriate RDFIs and Credit Model – Data and Dollars Separate
transmits the ACH transaction in a batch to the
While standardized remittance data can accompany
RDFI by the Settlement Date.
a CCD or CTX payment, buyers sometimes convey
it using other networks or methods. This is
Settlement known as the data “re-association model” (or data
5. 
The ODFI debits the buyer’s/Originator’s and dollars separate), where the Receiver (seller)
account. The ACH Operator debits the ODFI receives payment through the ACH, but must re-
and credits the RDFI. The RDFI credits the associate the payment with the correct remittance
seller’s/Receiver’s account on the Settlement information coming from another source, such
Date for the amount of the payment.

FIGURE 39-2

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG67
SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

as a value added network (VAN). This method Seller-Initiated Payments: Debit Model
requires the Receiver to have an identifier that Seller-initiated corporate ACH transactions are
can associate the payment with the remittance for debit transactions. When the seller initiates an
proper reconciliation in the accounts receivable ACH debit, the seller is the Originator of the ACH
system. See Figure 39-2. transaction and the buyer is the Receiver. The
seller debits the buyer’s account for the amount of
Payment initiation and settlement occur similar to payment due on an agreed upon date. Figure 39-3
the data and dollars together credit model above. illustrates this model.
The difference between these buyer initiated
payment models is how remittance data flows to Payment Initiation
the seller (2a). In the re-association model, where
1. 
Similar to buyer-initiated ACH transactions,
data and dollars are separate, the buyer sends
the use of ACH debit as the payment method
remittance data (per the seller’s specifications) to
is typically preauthorized in a trading partner
a VAN, which then routes the data to the seller.
agreement established between the buyer and
The seller then has to re-associate, or reconcile,
seller. At a minimum, the buyer must provide
the payment credit with the remittance data.
the seller with the ABA number (i.e.; the bank

FIGURE 39-3

OG68 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

routing number) of its financial institution and Remittance

its depository account number. This information In a seller-initiated ACH transaction, the seller
is used by the seller to debit the buyer’s account. is initiating an ACH debit solely for payment
The seller may issue a prenote in advance of collection purposes. Typically, the seller has the
the first live transaction to ensure the accuracy remittance information required to accurately post
of the buyer’s account information. the payment. The CCD format is typically used
for seller-initiated ACH debit transactions. If the
2. 
The seller, which is the Originator of the seller is collecting for multiple invoices or needs
ACH transaction, initiates an ACH debit by to document disputed line items, they may use a
sending debit instructions through its financial CTX or CCD plus addenda to relay the remittance
institution, the ODFI. The seller must use the information to the buyer as noted in step 6a.
format agreed to with the buyer in the trading
partner agreement. This is typically a CCD
REMITTANCE CAPABILITY
format because the seller generally does not
require any remittance data when it initiates Both CCD and CTX entries can carry payment
the payment by debiting the buyer’s account and remittance data together.  However, when
(although a CTX entry could be used). CCD remittance information is not required, the CCD
debits can be initiated by the seller using format without an addenda record is typically
information from its accounts receivable used. When it is necessary for remittance data to
system. accompany a payment, the type of remittance data,
along with the appropriate format, is specified
2a. 
The seller posts the payment to its accounts by the seller and communicated to the buyer in
receivable system based on initiation of the advance of the transaction.
ACH debit.
A CCD entry is limited in the amount of remittance
3. 
The ODFI formats the ACH debit per the data it can carry. Each CCD entry can accommodate
Originator’s instructions (or uses formatted one optional addenda record with a maximum of
data provided by the Originator) and transmits 80 characters of payment related information. A
the ACH transaction to the ACH Operator in a CTX entry can accommodate up to 9,999 optional
batch transmission one day prior to the desired addenda records each carrying 80 characters
Settlement Date. of payment related information, but the formats
allowed in the addenda are restricted to certain
4. The ACH Operator sorts, batches, and transmits standards. In CCD and CTX applications, the
the ACH transactions to the appropriate RDFIs. information contained in the remittance addenda
record is typically used for applying payment
Settlement related information.
5. The ACH Operator credits the ODFI and debits
While the B2B ACH payment vehicles—CCD and
the RDFI in the amount of the payment.
CTX—vary in the provision of remittance data,
they are consistent in providing certain payment
6. 
The RDFI debits the buyer’s, or Receiver’s,
related information, such as payment amount and
account on the Settlement Date.
payment date.
6a. In some cases, the RDFI provides remittance
data to the buyer. ADDENDA RECORDS
Addenda records may use American National
7. The ODFI credits the seller’s, or Originator’s, Standards Institute (ANSI) Accredited Standards
account with the ACH payment amount on the Committee (ASC) X12 transaction sets and data
Settlement Date. segments to relay payment related information.
The CCD addenda record can carry payment related

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG69
SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

ANSI ASC X12 data elements or data segments or to obtain a copy of the X12 Standards,
only, while the CTX addenda records can carry a please contact the Data Interchange Standards
full payment related ANSI ASC X12 transaction set Association (DISA) www.disa.org.
(i.e., one that contains a BRP or BPS data segment)
or payment related UN/EDIFACT syntax. Preparing the CCD Addenda Record
A CCD entry may relay remittance information
The ANSI ASC X12 transaction sets that contain using the “05” addenda record. Only one addenda
valid BPR/BPS data segments are: record may accompany each CCD entry. The
addenda record includes 80 characters of payment
• 103 Abandoned Property Filings – the 103 related information.
Transaction Set
Users of this payment format may insert any
• 521 Income or Asset Offset – the 521 NACHA-endorsed banking convention (i.e.,
Transaction Set child support, tax payment, or electronic dealer
drafting), or up to 80 characters of any combination
• 813 Electronic Filing of Tax Return Data – the of payment related ANSI ASC X12 data segments
813 Transaction Set and data elements — that is any combination of
data segments and data elements from the specific
• 820 Payment Order/Remittance Advice – the
transaction sets identified above. Data segments
820 Transaction Set
from other standards are not permitted in the
addenda record.
• 823 Lockbox – the 823 Transaction Set
An asterisk (“*”) must be used as the separator
• 835 Health Care Claim Payment/Advice – the
(or “delimiter”) between data elements, and the
835 Transaction Set
backslash (“\”) (referred to as the “terminator”)
must be used to indicate the end of a data
The NACHA Operating Rules do not specify which
segment.
version of the ASC X12 standards should be used.
However, the examples, definitions, and ASC X12
Preparing the CTX Addenda Record(s)
standards discussed in this chapter are derived
from the version release 5010 of the ASC X12 A CTX entry relays remittance information using the
Standards manual. For more information on basic ASC X12 Interchange Control Structure, Application
X12 rules, see Appendix J of these Guidelines. Control Structure, ANSI ASC X12 transaction sets
containing a BPR or BPS data segment (see list
Entries using the CCD format may also use NACHA- above), or payment related UN/EDIFACT syntax.
endorsed banking conventions to convey payment The addition of one or more addenda records to
related information within the addenda record. the entry detail record allows a corporation to
transmit payment related information; however, the
To receive information on NACHA endorsed presence of an addenda record is not mandatory
banking conventions, please visit www.nacha. with CTX entries.
org.
• For CTX entries there is a limit of 9,999 addenda
Although this chapter refers to the ANSI ASC X12 per ACH payment.
Interchange Control Structure (ANSI ASC X12.5),
the ANSI ASC X12 Application Control Structure • Only the ASC X12 Interchange Control Structure
(ANSI ASC X12.6), UN/EDIFACT payment related (ANSI ASC X12.5), Application Control Structure
syntax, and the transaction sets shown above, it (ANSI ASC X12.6), ANSI ASC X12 transaction
does not discuss these standards in detail. sets containing a BPR or BPS data segment
(see above), or payment related UN/EDIFACT
To receive additional information about ASC information are permitted in the CTX addenda
X12 or UN/EDIFACT payment related syntax, record.

OG70 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 3 9   C O R P O R AT E C R E D I T O R D E B I T A N D C O R P O R AT E T R A D E E X C H A N G E E N T R I E S

• For CTX entries that use multiple addenda monetary entry, an amount of zero is placed in the
records, the addenda are, in effect, chained amount field of the entry indicating that the value
together with each succeeding addenda record of the transaction is zero; however, remittance
carrying the next 80 characters of the message. information is carried in the addenda to support
the zero dollar payment. Zero dollar payments
• An addenda sequence number is provided in the with remittance can be treated similarly to dollar
addenda record. The sequence number is “0001” payments in that they can be coded as debits or
for the first addenda record. Each succeeding credits to savings or demand accounts. Typically,
addenda must contain a number greater than zero dollar payments are embedded in an ongoing
the previous addenda. application where the transactions usually have
value; however, for a particular time period, such
• Standards developed by the ASC X12 are as in the tax or health care industries, no funds
developed for computer processing and are not are owed.
easily readable by human operators, since codes
are often used to relay information. A zero dollar entry can also be transmitted through
the ACH as a pre-advice, where remittance detail
• The format of the ASC X12 message within the is transmitted from the Originator to the Receiver
addenda records is referred to as “enveloping” prior to the actual payment. This process allows
since it is comparable to placing a message any problems with the remittance detail to be
within an envelope and attaching it to a payment worked out prior to the flow of funds. A zero
as it flows through the system. dollar transaction can be transmitted with both
CCD and CTX entries.
Preparing CTX addenda records requires the
preparation of a file of ASC X12 formatted Compression of the Data
information. Once the record formats are constructed, the X12
message is then divided into 80-character segments
Refer to Appendix J within these Guidelines for and inserted within the addenda records. The
a discussion on Basic ASC X12 rules, and to Payment Related area of the addenda should be
the Data Interchange Standards Association fully utilized by “compressing” the ASC X12 data.
(DISA) at www.disa.org for complete Compression is a procedure in which one segment
information on X12 requirements. immediately follows the preceding segment. If a
data segment is longer than eighty characters, the
The Originator may either prepare the CTX
payment related field of the first addenda record is
entries itself or pass the X12 information to its
completely filled and the data is “wrapped” to the
financial institution to prepare the ACH file,
payment related field in the next addenda record.
depending on the agreement that the Originator
(Fourteen characters of the addenda record
has with its ODFI. Any editing or formatting of
contain the tracking and control information
transaction information done by the ODFI can be
needed for ACH processing.) A maximum of 9,999
considered a value-added service performed by
addenda records may be generated for any one
that organization.
CTX message, allowing a message totaling nearly
800,000 bytes.
CTX entries may be produced by scanning the
information in the ASC X12 message. From the
Delimiters, Terminators, and Version Release
information contained in the data segments, the
NACHA record formats can be constructed. For CTX payments, the ASC X12 structure allows
the originator flexibility in selecting delimiters,
Addenda Information and Zero Dollar Entries terminators, and the Version Release Control
Number. The value of these elements will be
Corporate payments may carry a dollar value or no
defined in the ISA segment (see Appendix J on
dollar value. In the case of a dollar value entry,
Basic ASC X12 Rules in these Guidelines) and will
a dollar amount greater than zero is transmitted
be chosen by agreement between the Originator
with the remittance detail. In the case of a non-

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG71
SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

and Receiver. Corporate users should note that UNDERSTANDING CIE BUSINESS
delimiters and terminators must be contained in the MODELS
NACHA data character set (EBCDIC characters with
Once consumers authorize payments from an
a value greater than hexadecimal “3F” and ASCII
online banking application, payments to billers
characters with a value greater than hexadecimal
can be made using several different models. For
“1F”). Communication control characters, those
example, payments made at online banking sites
characters with an EBCDIC value of “3F” or less
can be transmitted to billers through the ACH
or an ASCII value of “1F” or less, interfere with the
Network, through other payment networks, or
processing systems of ACH Operators and RDFIs
even by check. The specific payment method
and cannot be used.
chosen can depend on the
By combining payments with Electronic Data
• use of a third-party to provide a financial
Interchange payment information, corporations
institution’s online banking service;
enjoy many benefits. The combination of payment
and payment information allows the corporation
• risk profile of the payer and/or the risk tolerance
to apply this information in an automated manner
defined by the payee;
upon receipt rather than manually reconciling
the data and dollars. In general, Electronic Data • electronic receivables services provided to the
Interchange provides a basis for complete end-to- biller; and
end automation of order entry information.
• ability for the consumer financial institution/
third party service provider to send the payment
electronically to the biller.
CHAPTER 40
The discussion below describes common process
Customer-Initiated Entries (CIE) flows for bill payments transmitted through the
ACH Network from online banking applications.
A Customer-Initiated Entry (or CIE entry) is a
credit entry initiated on behalf of, and upon the Financial Institution as Bill Payment Provider
instruction of, a consumer to transfer funds to a In this model, a financial institution operates its
Receiver. CIE entries are usually transmitted to a own bill payment system and is able to originate
company for payment of funds that the consumer ACH payments. See Figure 40-1. The financial
owes to that company and are initiated by the institution’s consumer customer authorizes
consumer through some type of online banking a payment through the FI’s online banking
product or bill payment service provider. With application, and the consumer’s financial institution
CIEs, funds owed by the consumer are “pushed” to transmits a credit to the biller’s (i.e., the Receiver’s)
the biller in the form of an ACH credit, as opposed financial institution using the CIE format. (Note:
to the biller’s use of a debit application (e.g., The consumer’s financial institution will often
PPD, WEB) to “pull” the funds from a customer’s rely on a third party to obtain payment routing
account. instructions for billers.) Once the CIE credit is
received, the RDFI credits the biller’s account, and
This chapter provides an overview of the passes the payment remittance information (i.e.,
fundamentals of the CIE application and its use in the customer’s account number with the biller and
the bill payment environment. Topics include basic the payment amount) to the biller. The biller then
explanations of various CIE bill payment models, credits the consumer’s account.
risks related to CIE usage, and best practices
for minimizing exception processing in the bill 1. 
Originator (consumer) approves the payment
payment arena. amount to the biller in an online banking
application.

OG72 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

FIGURE 40-1

2. ODFI (consumer’s bank) originates the CIE to but the bill payment service is actually operated by
the biller’s financial institution. a TPSP. Once the consumer approves a payment
from the online banking application (or portal),
3. RDFI (biller’s bank) receives CIE, and credits the TPSP’s own financial institution (rather than
biller’s (Receiver’s) account with RDFI. the consumer’s financial institution) will first
debit the consumer’s account at his financial
4. Biller (Receiver) receives remittance data and institution (using a WEB or PPD transaction) and
credits consumer’s account with biller. then transmit a CIE credit to the biller’s financial
institution (similar to the financial institution bill
Third Party Service Provider payment provider model described above). With
as Bill Payment Provider this model, two separate ACH transactions are
In this model, shown in Figure 40-2, a financial required to complete the consumer’s payment
institution uses the services of a Third-Party instruction.
Service Provider (TPSP) to support bill payment
for its online banking platform. This model also As an alternative to transmitting a CIE credit to
applies to third-party bill payment providers that the biller on the consumer’s behalf, the TPSP
offer bill payment services that are not associated may effect payment to the biller through other
with an online banking service. In these cases, the methods, depending on the services provided
bill payment service is usually provided through a to the consumer’s financial institution and the
portal or non-bank website. biller’s preferences for payment delivery. In lieu
of transmitting the payment to the biller through
In this scenario, the consumer’s financial institution the ACH, the TPSP may choose to use another
is a passive party to the transaction. This means payment network, or it may even send a check
that the consumer may log-in and access his if the TPSP’s financial institution does not have
financial institution’s online bill payment service, electronic routing information for a particular
biller.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG73
SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

FIGURE 40-2

1. 
Originator (consumer) approves the payment 3. 
ODFI (TPSP’s FI) originates a credit to the
amount to a biller using an online banking biller for multiple consumer payments using
application or portal service. (Note: The an individual CIE for each payment, or the
consumer’s financial institution has contracted payments may be bundled into a CTX transaction
with a TPSP to operate the FI’s online banking with the remittance details in accompanying
service. The TPSP has a separate relationship addenda records (data and dollars together).
with another (the TPSP’s own) financial
institution to originate and receive ACH OR the ODFI (third party processor FI) may
a.
transactions.) originate a CCD or CCD+ credit to the biller,
and send the remittance data separately to the
2. ODFI (TPSP’s FI) debits the consumer’s account biller outside the ACH Network (remittance
at the consumer’s FI by transmitting a PPD or re-association model).2
WEB debit.
2
While this chapter discusses the use of CIE for Third-Party Service
Providers using the ACH to transmit payments to billers on consumers’
behalf, the TPSP also has the option of transmitting a CCD or
CTX transaction to the biller. In this model, a TPSP with multiple
consumer customers paying the same biller may “bundle” the
payments to a single biller within a single CCD or CTX transaction.
Remittance data may accompany the CTX (data and dollars together),
or the remittance data could be sent directly to the biller outside the
ACH (remittance re-association model), which is the likely scenario if
the TPSP uses CCD. More information on this payment option can be
found within the CCD/CTX chapter in these Guidelines.

OG74 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

4. 
RDFI (biller’s bank) receives payment RECEIPT AND POSTING OF CIE
transactions, credits biller’s account at the ENTRIES — RDFIS AND BILLERS
RDFI, and provides the remittance detail to the
In the bill payment environment, payment posting
biller.
involves a two-step process:

CIE RISK PROFILE 1. 

The RDFI posts the entry to the Receiver’s
Generally, the use of the CIE application presents (i.e., biller’s) account and credits the Receiver
little risk for consumers, financial institutions, and with the amount of the CIE entry. (Note: In
billers. CIEs have a low return rate, and, because accordance with the NACHA Operating Rules,
CIEs are credits to the biller rather than debits the RDFI must make funds from ACH credits
to the consumer, the use of CIEs minimizes the available to the Receiver on settlement date.)
potential for biller settlement risk that would exist
with consumer debits returned as unauthorized or 2. 
The Receiver (biller) updates its accounts
because of insufficient funds. As an example, CIE receivables and credits the consumer’s account
funds are good funds to the biller upon settlement with the biller in the amount of the CIE entry.
at the RDFI (the biller’s bank), as opposed to debit The NACHA Operating Rules do not define a
applications, which can be returned for insufficient specific timeframe in which this must occur but
funds for up to 2 days after settlement. Similarly, instead provide the Receiver with a reasonable
consumer debit transactions are at risk for at least period of time after the entry is credited to
60 days after settlement since consumers have an the Receiver’s account to post the funds to the
extended period of time in which they may dispute consumer’s account with the Receiver — that is,
whether a debit was authorized. within the timeframe that the Receiver normally
posts credits. However, the Receiver must apply
Risk for CIE transactions mainly occurs as a result the funds from the credit as of the settlement
of the payment funding model used by the ODFI or date of the CIE entry (i.e. backdate the credit
Third-Party Service Provider. Two funding models to the consumer’s account to agree with the
are used by financial institutions and TPSPs: (1) settlement date of the CIE entry).
collected funds, and (2) risk or unverified funds.
In a collected funds model, the provider secures Typically, billers will post a payment within 24
the customer’s funds for the payment prior to hours of receiving remittance, or they will return
initiating or originating a credit to the customer’s the payment if the payment cannot be posted. Some
payee or biller. In a risk or unverified model, the billers, however, choose not to return unpostable
customer’s funds are secured at the same time payments but instead will investigate the source of
the credit is transmitted to the payee or biller. In the payment or wait for the consumer to contact
either model, a CIE transaction is originated to the them. Examples of unpostable payments can
payee or biller for the amount owed to complete include payments with incorrect information, such
the payment, and there is no risk for the RDFI or as an incorrect biller account number, which may
Receiver. mean that a biller is unable to determine who the
customer payment is from.
In either model, an offsetting debit originated
by the Third-Party Service Provider’s financial RDFI as Biller
institution to the consumer’s account will be Financial institutions can also be billers, for
applied to the customer’s account by his RDFI. example, when they offer loan products (e.g.,
The debit will contain the name of the company student loan, mortgage, credit card, etc.). There
to be paid (e.g. for bill payment transactions, the are numerous instances where a consumer may
payee or biller) to assist the consumer in account have a loan with one bank, and make payments
reconciliation. In a collected funds model, the on that loan from another bank. In this case,
customer’s financial institution may use an internal the ODFI (consumer’s bank) will identify the CIE
debit transaction. credit as a loan payment using Transaction Code

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG75
SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

52 (Automated Loan Account Deposit). (This Biller Bulk Changes

assumes that the ODFI maintains – or subscribes CIE exception processing can also result from
to — a biller directory that would indicate which “bulk changes” made by billers to their customer
bills are for loan products. Then, transaction code account numbers. These are changes made en
52 would automatically be assigned when the masse to a biller’s customer account number
consumer selects the biller loan product during his system as a result of a merger, acquisition, portfolio
payee setup in the online banking session.) sale, billing system change, or other reason. When
a biller conducts a wide-scale change to consumer
Any CIE entries containing a loan transaction account numbers, there is a ripple effect to the
code would be routed directly to the RDFI’s loan online bill payment service that is used by the
system.  The account number field contains the consumer. When such changes occur, there are
loan number in this case, so the loan payment can generally three paths that may be taken:
post directly to the loan system.
1. Consumers make changes to their online bill
CIE EXCEPTION PROCESSING payment service set-up as they become aware
Online bill payments that billers cannot post that the account number needs to be changed.
accurately and promptly upon receipt result in the This is generally a time-consuming process that
need for exception processing. The issues listed results in unnecessary costs to the industry
below are common causes of CIE processing stakeholders, and could result in decreased
problems. consumer satisfaction if the payment is untimely
or inaccurate.
ACH Operator Returns
2. 
Biller maintains a cross-reference file of the
By definition, CIE is a credit-only application. ACH
old and new account numbers on its system.
Operators will return any CIE entry that bears a
This is generally maintained for a limited
debit transaction code unless it is for the specific
period of time (e.g., 12 months) and will map
purpose of reversing a previously originated,
entries with the old account number to the new
erroneous CIE credit. The ACH Operator will
account number during this period Online bill
identify these types of returns using Return Reason
payments will reject after this period of time
Code R35 (Return of Improper Debit Entry).
unless the consumer’s online bill payment set-
ODFIs should ensure that each CIE entry contains
up is corrected.
an appropriate credit transaction code unless the
entry is explicitly identified as a reversal.
3. 
Biller proactively contacts the online bill
payment processors to coordinate the bulk
User Error changes.
The inclusion of an invalid customer account
number at the biller within the CIE entry is While there is no industry standard for billers and
generally the primary cause of exception items processors to communicate bulk changes, there
for payments originating from online banking is an opportunity to improve communication
systems. These customer account numbers include, between billers and processors about impending
but are not limited to, policy numbers, customer bulk changes that will help to minimize exceptions.
numbers, invoice numbers, etc., and are the The biller is in the best position to initiate the
means by which the biller recognizes the payer. discussion with the processors and ideally provide
(In a CIE entry, this number is located within the the correct account number to be used. In general,
Individual Identification Number of the CIE Entry processors require 7 – 14 days to implement the
Detail Record.) There are a number of reasons bulk changes.
why account numbers may be invalid. Common
problems involve typos, missing or extra characters, Billers, processors, and consumers will benefit
lack of consumer understanding, mismatched from the proactive communication of bulk changes
payments and bill, among other reasons. because:

OG76 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

– changes can be made on or shortly after the rather than the Originator (the consumer paying
effective date of the change; the bill). The identification of the Bill Payment
Service Provider in these fields provides the biller
– it eliminates the need for each consumer with the means to identify the Bill Payment Service
to update the account number through the Provider originating the transaction in the event
online banking/consolidator system which is that the biller needs to contact the Bill Payment
time consuming and subject to errors; and Service Provider concerning a customer inquiry or
error investigation.
– it dramatically reduces exception items.
Company Discretionary Data
For a biller to provide a bulk-change notification, In a CIE entry, the Company Discretionary Data
each processor will require secure biller-specific field within the Company/Batch Header Record
requirements that will be defined by the processor. identifies the name of the biller (i.e., the Receiver)
to which the entries are being transmitted.
Correcting Biller Account Numbers Through
the NOC Process Note: This is different from the typical use of
Notifications of Change (NOC) should be created this field for other SEC Codes, where Originators
by Receivers of CIE transactions (i.e., the payee and ODFIs may, at their option, include codes of
or biller) and transmitted via their RDFIs to notify significance to them for specialized handling of the
consumers and their financial institutions/bill entries within the batch. For non-CIE applications,
payment service providers when there is a change the Receiver is typically identified within the Entry
in the customer’s account number at the payee/ Detail Record.
biller. An NOC is originated when: (1) the payee
or biller changes a customer’s account number CIE Entry Detail Record
due to internal system requirements, or (2) the
payee or biller can post the payment but the Individual Name
original customer account number received from For CIE entries, the Individual Name field within
Originator was not correct. Change Code C09 the Entry Detail Record is used to provide the
– Incorrect Individual Identification Number – is Receiver with additional information to identify
used for this purpose. When an NOC is received by the payment — typically the name of the payor on
the ODFI/Originator, the Originator must update whose behalf the CIE entry was transmitted.
the customer’s payee or biller account number
within six banking days or prior to transmitting Note: This is different from other SEC Codes, where
the next CIE entry, whichever is later. the Individual Name is otherwise the name of the
Receiver of the payment.
FORMATTING AND TECHNICAL
REQUIREMENTS Individual Identification Number
ACH participants should be aware that CIE entries In a CIE entry, the Individual Identification Number
include some non-standard uses of certain fields field within the Entry Detail Record contains
when compared to other SEC Codes. the accounting number by which the payor (the
consumer) is known to the payee (Receiver/biller).
CIE Company/Batch Header Record This number is used by the Receiver to update
accounts receivable records, and should be the
Company Name and Company Identification number shown on an invoice, statement, billhead,
Fields or other communication as the reference. Numbers
For CIE entries, the contents of the Company may be policy numbers, customer numbers, invoice
Name and Company Identification fields in the numbers, meter numbers, etc.
Company/Batch Header Record identify the Bill
Payment Service Provider transmitting the entry

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG77
SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

CIE Addenda Record You can use a valid ANSI ASC X12 data segment
CIE entries may be accompanied by one “05” but the total number of characters, including
Addenda Record. delimiters and terminators can only be a maximum
of 80 characters.  The X12 data segments may
Payment Related Information Field allow for more than 80 characters but the ACH
Payment Related Information field is a maximum
Any payment-related ANSI ASC X12 data segment
of 80 characters. 
may be included within the Payment-Related
Information field of the CIE addenda record. This
enables billers and Bill Payment Service Providers
to transmit specific information related to the
payment that assists them when processing CIE
entries, such as consumer name or address.

The specific ANSI ASC X12 data segments that

are included within this field are decided upon
by agreement between the Bill Payment Service
Provider and the biller. Information transmitted
between the bill payment service provider and
biller may, for example, include a name, account
number with the biller, additional address
information, etc.

For Example:

N1*BY*John Smith*ZZ*123456789\
N4**VA*201714\

In the above example, the N1 (Name) and N4

(Geographic Location) data segments are used to
convey consumer name, account number, state, and
postal code data to further identify the consumer
to the biller.

When determining which segments should be

included, remember that the Payment Related
Information field is limited to 80 characters and
many ANSI ASC X12 data segments have variable
length fields. For example, the N1 segment can have
a minimum of 10 and a maximum of 63 characters
if all elements are used and the N4 segment can
contain a minimum of 13 and a maximum of 82
characters (ANSI ASC X12 Version Release 3060).

OG78 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

BEST PRACTICES FOR MINIMIZING

EXCEPTIONS – PAYEE SET-UP FOR
ONLINE BANKING

The table below summarizes a number of

recommended best practices for improving the
accuracy of account numbers accompanying
electronic bill payments. These scenarios focus on
minimizing the potential for error at the front-end
of the process — that is, what can be done prior
to transmitting a consumer’s first payment to a
biller from an online banking/consolidator system.
Additional scenarios provide recommendations for
internal processes that can be implemented after
the first payment exception is received.

PROCESS RECOMMENDED BEST PRACTICES

Biller provides information • Provide and maintain processing instructions on the processor’s EBPP Biller Directory: account number set up
for third party processor parameters (e.g., account mask, check digit routine,), remittance information (e.g., remittance addresses), and
biller directories to other relevant information (e.g., alternative biller names)
facilitate payment • Provide exception error reports to processors and payment consolidators so EBPP Biller Directory and other
origination process from database updates can be made on a timely basis.
online banking/payment
• Work with processors and payment consolidators to exchange information on a periodic basis (e.g., monthly)
consolidator systems
using “scrub files”. Generally, the processor/payment consolidator will extract all of the consumer names and
account numbers associated with a unique biller on its EBPP Biller Directory (containing no dollar amounts).
The biller will match the consumer data on the processor/payment consolidator system with its internal system,
and provide the processor/payment consolidator with corrections showing the incorrect (“old”) and correct (“new”)
account numbers. The processor/payment consolidator will use this information to update its systems, and
preferably, reflect the new, updated account number on the consumer’s payee set up on the online banking/
consolidator site.
• Establish procedures for monitoring and reporting exception items. Send corrections to processor/payment
consolidator on a daily, monthly or at least a quarterly basis.
• Provide additional data to processor/payment consolidator such as consumer account name when a biller issues
the same account number to different customers within its system.
Biller provides consumers • Use the same account number for online bill payments as the one shown on the remittance coupon.
with clear online • Ensure the account number to be used for online bill payments is clearly defined and highlight the account
bill payment set-up number on the paper bill.
instructions.
• Provide instructions and examples on your website that demonstrate where the account number is on the
paper bill, and what identifier(s) need to be provided when making an online bill payment via online banking/
consolidator providers.
Processors manage/monitor • Enforce “front end” consumer data entry rules, and apply account edits early in the consumer data entry process.
payee setup and payment • When the consumer is setting up the account number for a biller, provide consumer with an error message if the
origination account number does not match the biller’s instructions on the EBPP Biller Directory (e.g., check digit routine,
prohibit consumers entering “NA” or “free checking”, etc. as remittance information).
• When consumer enters incorrect account number, provide consumer with online self-help and instructions.
• Implement strong biller account number edits (e.g., length, data type, beginning prefix numbers such as
BINs – Bank Identification Numbers, and check digit routines) when possible.
• Monitor the number and frequency of exception items and make adjustments to account number edits as needed.
• Work with billers to improve setup process by ensuring account masks have been defined. Fine-tune the masks/
edits, and remove them where they cause default to paper.
• Work with billers to be able to verify posting and account information.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG79
SECTION V – Standard Entry Class Codes
C H A P T E R 4 0   C U S T O M E R - I N I T I AT E D E N T R I E S

PROCESS RECOMMENDED BEST PRACTICES

Biller and processor Billers

ongoing processes • Understand that payment processor should not be responsible for blocking payments for closed consumer
accounts with billers.
• Try to locate a new account for the customer; if available, billers should post the payment and send correction
notice to payment consolidator.
• Provide scrub files to online bill payment processors to proactively correct consumer account numbers.
Processors
• Dedicate teams to process biller updates on the front-end online banking systems/consolidators and evaluate
potential impact before any update occurs.
• Build a biller contact network with the front-end online banking systems/consolidators for facilitating updates,
scrub files and escalating significant payment issues/trends for a specific biller or block of consumer account
numbers.
• Develop/maintain a secure way to communicate with consumers using online banking systems/consolidators.
• Establish an electronic sharing process of exceptions so that billers are aware of exceptions on a timely basis.
• Provide billers with an online application to allow billers to securely communicate corrected information.
• Review check images. Make changes to the consumer’s account number when biller has noted correct account
number on cancelled check.
Both
• Ensure regular and continuous communications.
• Work closely together to implement re-routing processes for corrected account numbers. (Positive files.)
Biller communicates • Contact consumers who have had three or more exceptions.
with the consumer after • Call consumers who have not updated their account number and work with them directly to update the number
receiving a payment contained on the online bill payment system.
exception
• Send mail to the consumers advising them to update their account information online.
• Clearly communicate account number changes along with a reminder to update online bill payment information
before the next payment is scheduled or executed.
Biller develops internal fixes • Consider very “loose” edits if effective exception handling processes can be developed (e.g., cross reference
tables).
• Determine exception handling policies (e.g., do not refuse payment unless it is obviously not for your company)
that are in compliance with specific regulatory obligations
Biller proactively • See Biller Bulk Changes discussion in this chapter.
communicates with third
party processors about
bulk changes

OG80 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

• a reduction in the need to maintain multiple

CHAPTER 43 bank relationships globally; and
International ACH Payments
• settlement on a specified value date.
(IAT)
Exchanging ACH payments internationally does,
however, present certain challenges:
The NACHA Operating Rules require ODFIs and
Gateways to identify all international payment • no Global or International ACH Operator
transactions transmitted via the ACH Network currently exists;
as International ACH Transactions using the
IAT Standard Entry Class Code. IAT transactions • no internationally utilized standard for batch
include specific data elements3 defined within the processing is available;
Bank Secrecy Act’s (BSA) “Travel Rule4” so that
all parties to the transaction have the information • no common set of rules exists;
necessary to comply with U.S. law, which includes
the programs administered by the Office of Foreign • no international counterpart to the U.S.
Assets Control (OFAC). These requirements of prenotification process is available;
the Rules are aligned with OFAC compliance
obligations, making it easier for RDFIs to comply • settlement times vary by country;
with those requirements.
• different formats exist for account numbers and
OVERVIEW bank routing numbers;
International ACH Transactions
• holiday schedules vary by country;
The domestic ACH Network facilitates batch
payment processing within the U.S., providing users • reversals are not allowed in many countries;
with next-day or two-day settlement capabilities.
International payments are credit and debit • debit rules vary by country;
payment instructions exchanged electronically
across national borders to transfer value between • some clearing systems have local language
an Originator (sender) and a Receiver (beneficiary). requirements; and
The use of international ACH payments provides a
cost effective method for corporate clients to make • local currency is required for domestic payment
high volume payments to vendors or consumers in systems.
other countries by leveraging in-country clearing
systems of the other country. Inbound IAT Process Flow
Payment transactions that enter the U.S. and that
The benefits of international ACH transactions
are destined to be processed through the U.S.
are the same as domestic ACH payments in terms
ACH Network as (inbound) IAT transactions are
of safety, reliability, and security. In addition,
part of a payments chain that begins as a SWIFT
international ACH transactions also benefit users
or proprietary payment message from a financial
through:
institution in another country. The IAT file format
will, in most cases, not be used by payment
• a reduction in funds movement costs;
originators in other countries. These transactions
will be converted to the IAT format once the
• more predictable cash flow;
payment request reaches the U.S. financial

3
NACHA did not implement all aspects of the BSA “Travel Rule” with
the IAT SEC code. Only specific data elements were adopted. The IAT
does not include the dollar threshold established by the BSA “Travel
Rule”.
4
31 C.F.R. Part 103.33(g)

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG81
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

institution that serves as the U.S. ODFI. Outbound its correspondent bank (Bank C) in the U.S., along
IAT entries, while originated through the U.S. with funding instructions for the payments. Bank
ACH system, will reach the receiving financial C acts as the U.S. Gateway Operator (entry point
institution in the other country through a variety to the U.S.). Bank C receives the SWIFT message
of methods (e.g., SWIFT, proprietary networks, or and funding, creates the ACH files (IAT format),
possibly the domestic ACH system of the receiving and transmits the ACH file to the ACH Operator.
country). The IAT format is only used for The ACH Operator processes the file and transmits
international batch payment transactions where the transactions to the RDFIs for posting to the
some part of the payment process involves the U.S. Receivers’ accounts. Bank B would also be
ACH Network. identified as a Foreign Correspondent Bank in the
IAT Addenda Record for Foreign Correspondent
Figure 43-1 provides an illustration of an Bank Information. This addenda record is created
international payment inbound to the U.S. In by the U.S. Gateway Operator or its designate.
this example, Bank A in Germany originates a
SWIFT message on behalf of the Originating REGULATORY ENVIRONMENT
Company to its correspondent bank (Bank B) in
the U.K. The message requests that payments Federal Regulatory Agency Requests
be made in the U.S. via the ACH Network to the & Guidance
ultimate beneficiaries (Receivers), and funding OFAC has stated that financial institutions need
instructions for all transactions are included with to safeguard the U.S. financial system from
the message. Bank B sends the SWIFT message to terrorist and other sanctions abuses involving
international ACH payments. In the domestic

OG82 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

payment environment, ODFIs and RDFIs can rely OVERVIEW OF IAT RULE
on each other to ensure compliance with OFAC REQUIREMENTS
obligations with regard to their own customers.
For international payments, however, DFIs cannot
Identification of International Payments
rely on international counterparts for compliance With the implementation of the IAT SEC code,
with U.S. law. The examination procedures for ACH transactions originating from or transmitted
financial institutions’ risk-based OFAC compliance to an office of a financial agency located outside
are included in the Federal Financial Institutions the territorial jurisdiction of the U.S. are required
Examination Council’s (FFIEC) Bank Secrecy Act/ to be explicitly identified by the ODFI or Gateway
Anti-Money Laundering Examination Manual. Operator entering such payments into the U.S.
ACH Network. The following definition of
Identification of International ACH International ACH Transaction was established for
Transactions and Formats to Comply such transactions, to which the SEC code, IAT, and
with U.S. Law formatting requirements apply.
Under the IAT rules, international ACH payments
International ACH Transaction or IAT entry means
are identified by focusing on where the financial
a debit or credit entry that is part of a payment
agency that handles the payment transaction is
transaction involving a financial agency’s office
located, regardless of where any other party to
that is not located in the territorial jurisdiction of
the transaction (e.g., the Originator or Receiver)
the United States. For purposes of this definition, a
is located. Specifically, where any ACH entry
financial agency means an entity that is authorized
is part of a payment transaction that involves a
by applicable law to accept deposits or is in the
financial agency’s office that is not located within
business of issuing money orders or transferring
the territorial jurisdiction of the United States,
funds. An office of a financial agency is involved in
the ACH entry must be identified using the IAT
the payment transaction if it (1) holds an account
(International ACH Transaction) Standard Entry
that is credited or debited as part of the payment
Class Code. As a result, certain transactions that
transaction; or (2) receives payment directly from
are international in nature but were transmitted as
a Person or makes payment directly to a Person
PPDs or CCDs in the past are now required to be
as part of the payment transaction; or (3) serves
transmitted as IATs. The IAT format helps RDFIs
as an intermediary in the settlement of any part
comply with their obligations under U.S. law by:
of the payment transaction. These entries must
be originated using the IAT Standard Entry Class
• carrying the additional data requirements
Code.
included in the BSA’s “Travel Rule” (i.e.,
Originator name/physical address/deposit
The term “payment transaction” in the definition of
account number, Originator’s depository
an International ACH Transaction is not a defined
institution name, payment amount, Receiver
term within the NACHA Operating Rules, but OFAC
name/address/account number, and the
has requested that NACHA provide guidance to the
Receiver’s financial institution), as requested by
ACH participants on the use of the term.
OFAC; and
Within the IAT definition, payment transaction
• containing OFAC Screening Indicators to aid
refers to
financial institutions in effective interdiction of
unlawful transactions.
• an instruction of a sender to a bank to pay,
or to obtain payment of, or to cause another
The identification of these payments as international
bank to pay or to obtain payment of, a fixed or
transactions and the inclusion of data elements
determinate amount of money that is to be paid
from “Travel Rule”, as well as the means to convey
to, or obtained from, a receiver, and
OFAC screening results, enable the RDFIs to
comply with OFAC compliance expectations.
• any and all settlements, accounting entries, or
disbursements that are necessary or appropriate
to carry out the instruction.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG83
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

The IAT definition classifies international United States for ACH payment transactions. Also
payments based on the geographical location known as a “Gateway Operator.”
of the financial agencies (financial institutions
or money transmitting businesses) involved in The IAT application incorporates, within the
the transaction, instead of on the location of the sections of the Rules addressing ODFI and Gateway
other parties to the transaction (e.g., Originator or obligations, specific rules and requirements
Receiver). For example, payment transactions that for each of these parties when exchanging IAT
start as wires or interbank transfers from abroad entries. Specifically, Article Two (Rights and
and are converted to ACH entries by a U.S. financial Responsibilities of ODFIs, Their Originators and
agency would be covered under this definition. Third-Party Senders) includes provisions governing
On the other hand, ACH entries originated from an ODFIs when originating IATs, and Article Five
account at a U.S. DFI based on instructions from (Rights and Responsibilities of Gateways for IAT
the account holder residing abroad would not be Entries) addresses Gateway responsibilities.
covered, unless the instructions were included
with funding in a SWIFT or proprietary message Gateway Obligations
sent from a foreign financial institution to the U.S. Article Five (Rights and Responsibilities of
DFI. Similarly, domestic ACH entries funded over Gateways for IAT Entries) includes the following
the counter at a U.S. DFI would be excluded, while specific obligations for Gateways:
a similar entry funded at a foreign bank would be
included. (See attached “ACH Payment Scenarios: • to obtain authorization from the ODFI or a
Domestic or International?” for more examples customer of the Gateway to originate IAT
of how the IAT definition would apply to various entries;
payment situations.)
• to enter into an agreement with the ODFI
This definition does not apply to transactions that or a customer of the Gateway in which the
may involve data received or processed offshore, ODFI or the Gateway’s customer instructs it to
where the processing entity is not a party to the receive Outbound IAT Entries on the ODFI’s
transaction and such processing is incidental to or customer’s behalf for re-transmission to a
and does not alter the terms of the transaction. foreign country;
In these cases, the offshore party does not have a
direct financial stake in the transaction through an • to notify the intended RDFI when it has blocked
account relationship or settlement obligation (e.g., and/or rejected any Inbound payment transaction
consolidated corporate treasury departments or because the origination of an Inbound IAT Entry
contracted third-party data processors). for such transaction would violate U.S. legal
requirements (effective September 21, 2012);
IAT =
• to transmit a timely ACH return entry for any
Payment + Financial Agency + U.S. ACH Network
Transaction (Outside the Use of the IAT SEC
Outbound IAT entry that is returned to it by the
(Instruction + Territorial code is required IF Foreign Gateway in accordance with the foreign
Settlement) Jurisdiction of the the transactions flow law or foreign payment system rules by which
United States) through the U.S. ACH
Network at some point the Gateway is bound;

FIGURE 43-2 • to provide the Foreign Gateway with corrected

data contained within any NOC related to an
Inbound IAT entry within two banking days of
Obligations for Gateways and ODFIs the settlement date of the NOC (effective March
A Gateway under this rule is defined as follows: 16, 2012); and

Gateway means either an ACH Operator or a • to comply with U.S. laws and regulations.
Participating Depository Financial Institution that
acts as an entry point to or exit point from the

OG84 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

An ACH Operator acting as a Gateway also will be in understanding the parties and terminology
required to ensure that Inbound IAT entries are involved with an International ACH Transaction:
restricted to ACH credits only, with the exception
of reversals. Outbound IAT entries processed Foreign Correspondent Bank means a Participating
through an ACH Operator acting as a Gateway DFI in a foreign country that holds deposits
may be either credits or debits. owned by other financial institutions and provides
payment and other services to those financial
A Participating DFI acting as a Gateway is also institutions.
deemed to have assumed the responsibilities and
warranties of an ODFI (for Inbound IAT Entries) or Foreign Gateway Operator means a Gateway
an RDFI (for Outbound IAT Entries), pursuant to Operator that acts as an entry point to or exit point
Article Two (Rights and Responsibilities of ODFIs, from a foreign country.
Their Originators and Third-Party Senders) or
Article Three (Rights and Responsibilities of RDFIs IAT SEC Code
and Their Receivers), respectively. Participating The IAT application consolidates consumer and
DFIs acting as Gateways may originate both credit non-consumer international payments under the
and debit entries, inbound and outbound. same SEC code (IAT). Unlike the U.S., payment
formats used in other countries typically do not
Gateway vs. ACH Operator distinguish between consumer and business
The Federal Reserve provides a Gateway service transactions.
with its FedGlobal service. With this service, it
processes inbound IAT credit transactions, does The use of one SEC code for all international
an OFAC review of all inbound IAT transactions, payments requires ACH participants to treat
populates the OFAC Screening Indicator field, and international payments to consumer and business
reports the suspect transactions to OFAC. accounts in the same manner. As a result, the
longer timeframe associated with the return of
The Federal Reserve and EPN, as ACH Operators, unauthorized consumer transactions under the
will process all IAT transactions originated by DFIs Rules also applies to unauthorized entries to
as Gateways. They will perform all ACH Operator business accounts. Specifically, for Inbound IAT
edits on the IAT debit and credit transactions and entries, the return of any unauthorized IAT entry
deliver the IAT transactions to the RDFIs. The is required to be transmitted by the RDFI in such
ACH Operators will NOT do an OFAC review of time and manner that the return entry will be made
the IAT transactions. available to the ODFI/Gateway Operator no later
than the opening of the business on the banking
ODFI Obligations day following the sixtieth calendar day following
In addition to all other ODFI warranties and the settlement date of the original entry. (Note: For
obligations defined within Article Two (Rights and Outbound IAT entries, the time frames for return
Responsibilities of ODFIs, Their Originators and of an entry are determined by the payment system
Third-Party Senders), additional obligations for IAT rules of the foreign country and may exceed the
transactions relate to: (1) Originator authorization 60-day return window defined by the U.S. ACH
and agreement; (2) ODFI warranties for Outbound system.)
IAT entries with respect to compliance with U.S. law
and compliance with foreign payment system rules; Formatting Modifications
and (3) exceptions for Inbound and Outbound IAT Data Requirements
entries (refer to the NACHA Operating Rules for a The IAT format includes certain data elements
complete listing of exceptions). from the BSA’s “Travel Rule,” which is currently
required for wire transfers. The data elements
Identification of Participants in an IAT Entry listed below are included in the IAT format and
The following definitions are included in Article all fields correspond to the SWIFT message format
Eight of the Rules to assist ACH participants field lengths to allow for greater interoperability.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG85
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

• Name and physical address of the Originator The Foreign Correspondent Bank addenda record
is used only for inbound IAT transactions to
• Name and physical address of the Receiver identify any intermediary foreign bank involved in
(“Beneficiary”) the transactions between the foreign originating
bank and the U.S. Gateway Operator.
• Account number of Receiver
(Note: A maximum of twelve addenda records
• Identity of the Receiver’s bank may be transmitted with an IAT entry. Seven of
these addenda records are mandatory and contain
• Foreign Correspondent Bank(s) name, Bank ID the travel rule information identified above. Five
number and Bank Branch Country Code additional addenda records (i.e., remittance and
foreign correspondent bank detail) may also
Mandatory Addenda Records accompany each entry.)
Seven mandatory Addenda Records must accompany
each IAT entry in order to convey the information OFAC Screening Indicators
listed above. All information related to a particular The IAT format includes two optional, single-
ACH participant is grouped together within one character fields within the Entry Detail Record to
or more addenda records (e.g., information related convey the results of voluntary OFAC screening
to the Originator will be provided together within on the transaction. For Inbound IAT entries,
one or more addenda records). the first field is available to convey the results
of an OFAC screen by a Gateway Operator, and
Optional Addenda Records for a secondary screening indicator is available to be
Remittance Information used by a third-party service provider to convey
IAT entries accommodate the transmission of such screening results. A value of “0” indicates
optional remittance information. A maximum of that the party conducting the screening has not
two optional addenda records can accompany found a potential blocked party, as identified by
an IAT entry, within which a maximum of 160 OFAC on its list of Specially Designated Nationals
characters (80 characters per addenda record) (“SDN list”). A value of “1” indicates the potential
of remittance information can be included. This presence of a blocked party. The field must be
enables standard 4x35 remittance information in space-filled if no screening has been conducted.
a SWIFT message or Fedwire-formatted record These OFAC screening indicators assist RDFIs
to be included within an IAT entry. There are processing international payments with their
no formatting specifications for the optional compliance obligations by identifying entries that
remittance information except for those banking are highly suspect.
conventions that have been developed to carry
mandatory information for secondary SEC codes The Federal Reserve Bank’s Retail Payments Office,
identified in the Transaction Type Code field. on behalf of the Federal Reserve in its capacity of a
Gateway Operator, screens Inbound IAT entries for
Addenda Records for Foreign Correspondent OFAC compliance, as requested by OFAC. It advises
Bank Identification the RDFI, through the use of an OFAC Screening
A separate addenda record must be added to the Indicator, of potential issues and, subject to OFAC’s
payment for each Foreign Correspondent Bank that approval, utilizes FedLine Web to advise the RDFI
is involved with the transmission or exchange of an of Inbound IAT transactions that contain data
IAT entry. Any Foreign Correspondent Bank that appearing on the OFAC “SDN List.” The Electronic
is involved in an IAT transaction must be identified Payments Network (EPN), the private-sector ACH
within an addenda record, providing parties to the Operator, also makes available an OFAC screening
transaction with additional information needed function to its customer financial institutions as a
to identify and react to unlawful transactions. A value-added service.
maximum of five Foreign Correspondent Bank
addenda records may accompany an IAT entry. The OFAC Screening Indicator should only be used
as a reference and not the final determining factor
for OFAC compliance by the RDFI.

OG86 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

Returns and Notifications of Change on data obtained from the Gateway, changes
for International ACH Transactions related to other information carried within an
international payment are generally not applicable
IAT Returns
to international payments and are not supported
The seven mandatory addenda records that under the IAT application. NOCs related to IAT
accompany a forward IAT entry are required to entries have unique formatting requirements based
be transmitted with any IAT return entry. An IAT on data requirements associated with international
return is also required to include one additional payments, requiring development of a distinct set
addenda record within which specific information of formats (company/batch header record, entry
related to the return (such as return reason code, detail record, and addenda record) for these
original entry trace number, etc.) is included. NOC entries. NOCs related to IAT entries are
Addenda records related to Foreign Correspondent distinguished from domestic NOCs through the use
Banks and those containing remittance information of an “IAT Indicator” code within the Company/
are not copied for return to the Originator. Batch Header Record.
These IAT return formatting requirements differ Unlike the IAT return process, the seven mandatory
from domestic ACH return processing. For the addenda records, the remittance addenda records,
return of domestic transactions, addenda records and the Foreign Correspondent Bank addenda
transmitted with forward entries are not returned records transmitted with the forward IAT entry
by the RDFI, as they contain only remittance are not needed to process the NOC and are not
information and are not necessary to identify included. The transmission of Refused NOCs is
the original transaction or process the associated not supported by the IAT rules.
return. IAT addenda records, however, contain key
data related to the payment itself, and the return of (Note: For an Outbound IAT entry, where the RDFI
such information is needed to adequately identify resides in a foreign country, the rules governing
the original transaction and process the return. NOCs apply only to the extent that the NOC
process is supported by the payment system rules
Dishonored and Contested Dishonored Returns of the foreign receiving country. However, for
Not Permitted for IAT Entries an Inbound IAT entry, where the RDFI is a U.S.
Dishonored and Contested Dishonored Return financial institution, NOC rules apply as they do to
entries are not be permitted for use with IAT entries. other, domestic entries. Where a U.S. RDFI initiates
These domestic exception processes do not have an NOC in relation to an Inbound IAT entry, the
counterparts within foreign payments systems, Gateway is obligated (as of March 16, 2012) to
requiring issues beyond return of the original provide any corrected data contained within that
transaction to be resolved through channels other NOC to the Foreign Gateway within two banking
than the dishonor/contested dishonor process. days of the settlement date of the NOC.)
Information obtained from Gateways under the
prior cross-border process indicated that the Exemption from Rules Obligations –
volume of exception situations requiring additional IAT Processing and the Effect of Illegality
handling of returned entries was extremely low A Participating DFI must process each IAT entry
and that manual handling of such issues had been in accordance with all requirements of the NACHA
adequate in resolving problems related to these Operating Rules. A DFI is excused from its
payments. Based on this information, and on compliance with specific obligations under the
additional complexities involving foreign exchange Rules only when the processing of an IAT entry
conversion, the Rules prohibit IAT return entries would cause the DFI to be in violation of U.S.
from being dishonored or contested. law. The DFI must, therefore, comply with its
obligations under the NACHA Operating Rules, and
IAT Notifications of Change any other legal requirements related to the Entry,
RDFIs can transmit changes related to routing unless it identifies an IAT as a suspect transaction.
numbers and account numbers for IAT entries via For domestic RDFIs that receive inbound IATs,
the Notification of Change (NOC) process. Based these obligations include, but are not limited

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG87
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

to, the timely provision of funds and the timely When a financial institution credits a
transmission of returns. beneficiary’s account with the proceeds
of a transaction that is in violation of
A suspect transaction, for purposes of OFAC OFAC regulations, it has committed a
compliance5, is one that potentially involves or violation by processing the transaction
relates to a “specially designated national” (SDN) forward. The consequences of the
or “blocked party,” and requires more detailed violation can be mitigated if the
examination by the Participating DFI to determine institution is able to prevent the
whether the entry violates OFAC sanctions. For beneficiary’s access to the funds until
these suspect entries only, the Rules, through the OFAC screening is completed, or is
the effect of illegality provision, excuse the otherwise able to recover the funds prior
Participating DFI from its obligations to comply to their being used by the beneficiary.”
with any provision of the Rules, such as crediting
or debiting an account, if such compliance is A copy of OFAC’s letter can be found on the
inconsistent with U.S. law. IAT Resource page on the NACHA website at
www.nacha.org
Following the implementation of the IAT
application, NACHA received reports that some ACH PAYMENT SCENARIOS: 
domestic RDFIs were liberally applying the DOMESTIC OR INTERNATIONAL?
provision on the effect of illegality. In these cases,
Several scenarios are provided below to better
RDFIs assumed that, solely because entries were
understand when a specific payment transaction
coded as IATs (and not because the entries were
involving the U.S. ACH Network should be
suspect transactions), they did not have to meet
deemed an International ACH Transaction (IAT)
the requirements of the Rules (including, but not
or a domestic ACH transaction. In all scenarios,
limited to, timely provision of funds or returns).
the location of the financial agencies involved
This is inconsistent with the requirements of the
in the settlement of the transaction is the key
Rules and, as with any other infraction of the
determining factor. The term “financial agency” is
Rules, can subject the DFI to enforcement action
primarily intended to mean a depository financial
through the National System of Fines.
institution, but it also covers money transmitting
businesses to the extent they are involved in the
Timing of OFAC Screening of IAT Transactions
payment transaction.
NACHA has received reports that some RDFIs do
not screen IAT entries for OFAC compliance prior While the scenarios described below represent an
to posting them to the Receiver’s account. In some assessment of situations that are likely, they are
cases, this is due to system or software constraints not all-inclusive as to the types of transactions and
at the RDFI. NACHA contacted OFAC requesting situations that might give rise to a determination of
comment on this practice and received a letter an IAT or a domestic ACH transaction. Domestic
from OFAC (GEN-594137) stating its position. In transactions are listed in scenarios A, B, C/D,
the letter, OFAC states: and part of the transactions for scenario F. IAT
transactions are listed in scenarios C/D - Alternatives
“It is OFAC’s position that a financial 1 & 2, E, G, H and part of the transactions for
institution that performs its OFAC scenario F.
screening after having credited a
beneficiary’s account increases its OFAC Each scenario involves defined parties as recognized
risk substantially. in the NACHA Operating Rules that govern IATs
under the IAT SEC code.

5
 his is for information purposes only, and is not intended to provide
T
legal advice. Readers should seek advice from legal advisors with
regard to their obligations under programs administered by the U.S.
Department of the Treasury’s Office of Foreign Assets Control.

OG88 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

NOTE: Immediately following each detailed

Simplified Scenario A –
scenario is a “simplified” recap of the scenario U.S. Domiciled Company/
to assist in the evaluation of the scenario. While Standard Direct Deposit
the detailed scenarios have been reviewed and
• U.S. domiciled company
approved by OFAC, the simplified scenarios have
• No direct funding for the payroll from outside the territorial
not. jurisdiction of the United States
• ACH file information created by or for the U.S. company and sent
Scenarios to their U.S. bank
• All employees’ ACH deposits are being sent to banks within the
Scenario A – Payroll: territorial jurisdiction of the United States.

A U.S.-domiciled company with 500 U.S.- Domestic transactions, formatted as PPD transactions
resident employees is a subsidiary of an offshore
multinational corporation with its headquarters in
Europe. Revenues are generated through domestic Scenario B – Payroll:
business activities of the U.S.-domiciled company. A U.S.-domiciled company with 500 U.S.-
resident employees is a subsidiary of an offshore
Twice monthly, the U.S.-domiciled company multinational corporation (the parent company).
sends payroll payment instructions for all 500 U.S. The parent company has centralized many of
employees in a single file to its New York bank the global treasury, human resources, and data
where it holds an account. processing functions of its global subsidiaries
(including the U.S. subsidiary) at its headquarters
Upon receipt of the payroll information from in Europe.
the U.S.-domiciled company, the New York bank
executes the following payment transactions: Twice monthly, the U.S. subsidiary sends the parent
company any changes to employee status, salaries,
• Originates an ACH file of 420 credit entries to hours, etc. Also, twice monthly, after updating
pay 420 of its employees on settlement date, with its central HR records, the parent company sends
an offsetting book-entry debit to the company’s payroll payment instructions for all U.S. employees
account at the New York bank totaling the sum in a single file to its New York bank on behalf
value of all 420 credit entries; of the U.S. subsidiary, which holds an account
with the New York bank. Funding for payroll is
• Prints and ships to the company 80 payroll generated through business activities of the U.S.
checks (and 500 payroll stubs), drawn on the subsidiary.
company’s U.S. bank account at its New York
bank, to pay those U.S. employees not on Direct The New York bank receives the U.S. subsidiary’s
Deposit. payroll file from the parent company, and executes
the following:
Result – Domestic or IAT?
All 420 ACH credits and the single, offsetting debit • Originates an ACH file of 420 credit entries to
in this scenario would be domestic transactions pay 420 U.S. employees on settlement date,
and not IATs (the credits would be PPD entries; with an offsetting book-entry debit to the U.S.
the debit typically would be an on-us DDA entry). subsidiary’s account at its New York bank
This is because the New York bank and the RDFIs totaling the sum value of all 420 credit entries;
holding the employees’ accounts are the only
financial agencies involved in the transactions • Prints and ships to the U.S. subsidiary 80 payroll
and they are all in the territorial jurisdiction of checks (and 500 payroll stubs), drawn on the
the U.S. subsidiary’s U.S. account at its New York bank
to pay those U.S. employees not on Direct
Deposit.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG89
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

Result – Domestic or IAT? Upon receipt of the payroll file for the U.S.
All 420 ACH credits and the single, offsetting debit subsidiary from the parent company, the European
in this scenario would be domestic transactions bank instructs the bank in New York via a SWIFT
and not IATs (the credits would be PPD entries; message (or proprietary system) to execute the
the debit typically would be an on-us DDA entry). following payment transactions:
This is because the New York bank and the RDFIs
holding the employees’ accounts are the only banks • Originate an ACH file of 420 credit entries to
involved in the transactions. No financial agencies pay 420 U.S. employees on settlement date,
located outside of the territorial jurisdiction of the with a debit to the U.S. subsidiary’s account at
U.S. are involved in the payment transactions. its New York bank totaling the sum of all 420
credit entries;

Simplified Scenario B – • Print and ship to the U.S. subsidiary 80 payroll

U.S. Subsidiary of a Offshore
checks (and 500 payroll stubs), drawn on the
Multinational Corporation
U.S. subsidiary’s account at its New York bank,
• U.S. domiciled company to pay those U.S. employees not on Direct
• No direct funding for the payroll from parent company. The funding Deposit.
is for general operating activities of the company and not for a
specific ACH file. [Funding can be from U.S. company activities
or received as part of a regular funding of the company activities Result – Domestic or IAT?
by the parent on a daily, weekly, monthly basis for all check, wire All 420 ACH credits and the offsetting book-entry
transfer, card or ACH activity.]
debit to the U.S. subsidiary’s account in this scenario
• ACH file — may or may not have been originated by parent
company would be domestic transactions and not IATs. This
• All employees’ ACH deposits are being sent to banks within the is because no foreign financial institution/agency
territorial jurisdiction of the United States. was involved in the payment transaction, which
Domestic transactions, formatted as PPD transactions
started with the parent company instructing its
European bank to originate a SWIFT message to
the New York bank with instructions to pay the
Scenario C – Payroll: employees. The European bank is not involved
A U.S.-domiciled company with 500 U.S.- in the transaction as it did not debit or credit the
resident employees is a subsidiary of an offshore parent company’s account as part of the payment
multinational corporation (the parent company). transaction. Nor did it serve as an intermediary
The parent company has centralized many of in the settlement of the payment transaction.
the global treasury, human resources and data Instead, the European bank was only involved in
processing functions of its global subsidiaries the transmission of the SWIFT payment instruction.
(including the U.S. subsidiary) at its headquarters The SWIFT message specifically instructed the New
in Europe. It has also centralized many of its HR- York bank to debit the U.S. subsidiary’s account and
related banking functions with an international not the European bank’s correspondent account at
bank headquartered in Europe. the bank in New York.

Twice monthly, the U.S. subsidiary sends any

changes to employee status, salaries, hours, etc.
to the parent company. Also twice monthly,
after updating its central HR records, the parent
company sends payroll payment instructions for
all 500 U.S. employees in a file to its international
bank in Europe on behalf of the U.S. subsidiary.

OG90 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

• Originate an ACH file of 420 credit entries to

Simplified Scenario C –
U.S. Subsidiary of a Offshore pay 420 U.S. employees on settlement date, with
Multinational Corporation a debit to the U.S. subsidiary payroll settlement
account at the New York bank totaling the sum
• U.S. domiciled company
value of all 420 credit entries;
• No direct funding for the payroll from parent company. The
funding is for general operating activities of the company and
not for a specific ACH file. [Funding can be from U.S. company • Print and ship 80 payroll checks (and 500 payroll
activities or received as part of a regular funding of the company stubs), drawn on the New York bank for the U.S.
activities by the parent on a daily, weekly, monthly basis for all
check, wire transfer, card or ACH activity.]
subsidiary, to pay those U.S. employees not on
• ACH file enveloped in a SWIFT message from a European bank Direct Deposit.
to a U.S. bank that originates the file into the U.S. ACH Network
• All employees’ ACH deposits are being sent to banks within the Result – Domestic or IAT?
territorial jurisdiction of the United States
All 420 credit transactions would be IATs and not
Domestic transactions, formatted as PPD transactions. Even domestic. This is because the European bank is
though the ACH payment instructions were sent via SWIFT
message through a foreign financial agency, there were no
involved in the payment transaction by debiting
funds sent into the country. the parent company’s account in Europe and by
serving as an intermediary in the settlement of
the payment transaction as a result of funding
Scenario C – Alternative #1: the SWIFT message by debiting its correspondent
(changed circumstances in italics) account.
A U.S.-domiciled company with 500 U.S.-
resident employees is a subsidiary of an offshore Similarly, if the payment instruction involved
multinational corporation (the parent company). another funding mechanism, this scenario would
The parent company has centralized many of result.
the global treasury, human resources and data
processing functions of its global subsidiaries Scenario C – Alternative #2:
(including the U.S. subsidiary) at its headquarters in (changed circumstances in italics)
Europe. The parent company has also centralized A U.S.-domiciled company with 500 U.S.-
many of its HR-related banking functions with an resident employees is a subsidiary of an offshore
international bank headquartered in Europe. multinational corporation (the parent company).
The parent company has centralized many of
Twice monthly, the U.S. subsidiary sends the parent the global treasury, human resources and data
company any changes to employee status, salaries, processing functions of its global subsidiaries
hours, etc. Also twice monthly, after updating its (including the U.S. subsidiary) at its headquarters in
central HR records, the parent company sends Europe. The parent company has also centralized
payroll payment instructions for all 500 U.S. resident many of its HR-related banking functions with a
employees in a file to its European bank on behalf European bank also headquartered in Europe.
of the U.S. subsidiary. These instructions include
a request to debit the parent company’s account Twice monthly, the U.S. subsidiary sends the parent
with the European bank to fund the payroll file on company any changes to employee status, salaries,
behalf of its U.S.-domiciled subsidiary. hours, etc. Also twice monthly, after updating its
central HR records, the parent company sends
Upon receipt of the payroll file for the U.S. payroll payment instructions for all 500 U.S.
subsidiary from the parent company, the European employees in a file to their European bank on
bank debits the account of the parent company. behalf of the U.S. subsidiary. The European bank
It then sends a SWIFT message to the New York maintains a correspondent banking relationship in
bank with instructions to: the United States with a New York bank.

• Credit its correspondent account at the New Upon receipt of the payroll file for the U.S.
York bank on behalf of its U.S. subsidiary; subsidiary from the parent company, the European

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG91
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

bank instructs its correspondent bank in New York company). The parent company has centralized
via a SWIFT message (or proprietary system) to many of the global treasury, human resources, and
execute the following: data processing functions of its global subsidiaries
(including the U.S. subsidiary) at its headquarters
• Debit the European bank’s correspondent in Europe.
account at the New York bank in the amount of
the sum of all 500 payroll payments and credit All invoices for the U.S. subsidiary are sent to
an account of the U.S. subsidiary for the payroll the parent company for processing and payment.
file; Twice monthly, the parent company originates
a file to its European bank to pay outstanding
• Originate an ACH file of 420 credit entries to invoices for their U.S. subsidiary. The European
pay 420 U.S. employees on settlement date, with bank instructs a New York bank via a SWIFT
a debit to the account of the U.S. subsidiary message (or proprietary system) to execute
payroll settlement account at the New York bank payment transactions on behalf of the parties. As
totaling the sum value of all 420 credit entries; in Scenario C and its alternatives, the payment
instructions and related funding transactions may
• Print and ship to the U.S. subsidiary 80 payroll vary.
checks (and 500 payroll stubs), drawn on the
New York bank for the U.S. subsidiary, to pay Result – Domestic or IAT?
those U.S. employees not on Direct Deposit. This scenario and its various alternatives in terms
of location of parties, funding and types of payment
Result – Domestic or IAT? instructions are identical to Scenario C with the
All 420 credit transactions would be IATs and not exception that the payments are commercial
domestic. This is because the European bank is a in nature and not consumer. Therefore, the
foreign financial institution that is involved in the determination of whether the commercial ACH
payment transaction in a number of ways. The transactions are domestic or IATs is the same.
European bank, which is the Originator’s bank, is
part of the settlement of the transaction with the
Simplified Scenario D –
New York bank by sending and funding the SWIFT
Vendor Payments
message through correspondent banking.
• Vendor payments would follow the logic associated with Scenarios
A, B, & C listed above.
Simplified Scenario C Alternative 1 and 2 – • See simplified scenarios above.
U.S. Subsidiary of an Offshore
Multinational Corporation
Scenario E – ACH Debits for Payments
• U.S. domiciled company
to Foreign Receivers:
• Direct funding for the payroll file from the parent company through
a foreign financial agency outside the territorial jurisdiction of the An offshore bank provides a service allowing
United States. Persons in the U.S. to send funds easily and
• Payroll information, whether in SWIFT message, ACH file format,
economically to relatives or other Persons in the
or proprietary format tied to the specific funding is sent to the
companies U.S. bank. offshore bank’s country of domicile. The Person
• All employees’ ACH deposits are being sent to banks within using the service (Originator) logs onto a website
the territorial jurisdiction of the United States through the ACH and instructs the offshore bank (Originating Bank)
Network.
to make a payment to anyone in that country. The
International transactions, formatted as IAT transactions Originator keys the following information into
the website: Receivers name, physical address,
banking information, and the Originator’s own
Scenario D – Vendor Payments: routing and transit number and account number
A U.S.-domiciled company is a subsidiary of of its domestic bank and physical address. The
an offshore multinational corporation (parent offshore bank originates a SWIFT payment

OG92 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

instruction to its U.S. correspondent bank in New Scenario F – Pension Payments:

York, requesting it to originate ACH debits to its A U.S.-domiciled company makes pension
Originators in the U.S. and to credit the offshore payments to 450 U.S.-resident retirees and 50
bank’s correspondent account with the amount of retirees residing offshore.6 Twice monthly, the
the debits. The instruction contains the Receivers’ U.S. domiciled company sends pension payment
name, address, and other necessary information. instructions for all 500 retirees in a single file to its
The New York bank converts the SWIFT payment U.S. bank in Kansas City, where it holds an account.
instruction into an ACH file of debit entries. Upon receipt of the pension information from the
U.S. company, the Kansas City bank executes the
Result – Domestic or IAT? following payment transactions:
All the ACH debits originated by the New York
bank on behalf of the offshore bank would be • Originates an ACH file of 420 credit entries to
IATs and not domestic. The payment transactions pay 420 U.S. retirees on settlement date, with
involve Persons in the U.S. requesting the offshore an offsetting book-entry debit to the company’s
bank to cause payment to be made to Persons in account at the Kansas City bank for the total of
a foreign country. The offshore bank is involved the sum value of all 420 credit entries.
in these transactions in a number of ways. First, it
will ultimately credit (or instruct and fund another • Twenty of 420 Direct Deposit payments are to
bank to credit) the accounts of the Receiver in retirees that reside offshore but have identified a
the foreign country. Second, the offshore bank domestic banking routing number and account
is involved as an intermediary in the settlement number for pension payments.
of the payment transaction, as its correspondent
account at the New York bank is credited a part of • Ten of these 20 offshore retirees hold accounts
the transactions. with offshore banks (in their respective host
country) that, in turn, have a U.S. office in New
York (the routing number in each ACH pension
transaction is that of the U.S. office of the
Simplified Scenario E –
ACH Debits for Payments offshore bank).
to Foreign Receivers
• The other 10 offshore retirees also hold accounts
• A foreign bank (Originating Bank) allows non-bank customers to with offshore banks (in their respective host
make payments to consumers in their country.
country) and these banks hold correspondent
• A person (Originator) in the U.S. logs on to the foreign bank site
and orders a payment to a relative (Receiver) in that country, accounts with U.S. banks in New York (the
providing the bank with their routing and transit number (ABA routing number in each ACH pension transaction
number) and account number at their U.S. bank along with the
routing, account number and physical address of the Receiver in
is that of the U.S. correspondent bank).
the foreign country.
• The foreign Originating Bank sends a SWIFT message to their • Typically, the receiving bank (U.S.-domiciled
U.S. correspondent bank with instructions to send an ACH debit office or correspondent bank) will have
to the Originator’s account at their U.S. bank along with the name
and physical address of the Receiver in the foreign country. instructions on file to handle the transaction –
• The U.S. bank processes the debit to the U.S. Originator’s bank either on a book-entry transfer relationship (U.S.
and credits the correspondent account at their bank for the foreign office) or according to a correspondent posting
Originating Bank.
routine such that the proceeds can ultimately be
• The foreign Originating Bank sends a credit payment to the
Receiver’s account at the bank in their country. made available to the retiree (Receiver) in his
resident country.
The debit to the Originator’s account in the U.S. would be an
IAT transaction because the funds are moving out of the U.S. to
a foreign financial agency. • Prints and ships to the U.S. company 80 pension
checks (and 500 pension stubs), drawn on the
company’s account at the Kansas City bank,

 his scenario could also apply to Social Security benefit payments to

T
6

domestic and offshore residents.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG93
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

to pay those U.S. and offshore retirees not on Scenario G – ACH Credit Payments to
Direct Deposit. Foreign Receivers:
An offshore bank provides a service allowing
Result – Domestic or IAT? companies in the U.S. to send funds easily and
Four hundred of the 420 ACH credits and the single, economically to companies in its country of
offsetting debit in this scenario would be domestic domicile. The offshore bank holds a correspondent
transactions and not IATs (the credits would be account with a New York bank that can receive
PPD entries; the debit typically would be an on-us ACH credit entries (with remittance data), with the
DDA entry) because there are no foreign financial offshore company as ultimate Receiver. At the end
institutions involved in the transactions. Both the of the daily processing cycle, the New York bank
Originator’s bank in Kansas City and the Receivers’ sends to the offshore bank (1) a wire in the amount
banks are within the territorial jurisdiction of of the aggregate of the credits received/settled that
the U.S. day, and (2) an EDI file with the individual entry
detail and remittance information. This enables
However, the 20 ACH entries to U.S. accounts for the offshore bank to reconcile the settlement wire
further crediting to offshore retirees would be down to the customer level and provide each
IATs and not domestic, as they would all require customer the requisite remittance detail for his or
an offshore bank to credit the Receivers’ accounts. her individual payments.
It is the employer’s obligation to understand the
legal domicile of its retirees and inquire whether Result – Domestic or IAT?
they hold accounts in U.S. banks or with offshore All of the ACH credits received by the New York
financial institutions. The employer would have bank on behalf of the offshore bank would be
to recognize the need to provide the relevant IAT and not domestic since the offshore bank
information to the U.S. bank to facilitate origination holds accounts that would be credited as part of
of properly formatted IAT entries to its offshore the transactions. Therefore, the offshore bank’s
retirees. Because the Receivers’ accounts are held offshore customers should instruct their U.S.
with offshore banks, despite being destined to U.S. trading partners to originate ACH entries using the
bank accounts, the transactions would be IATs. IAT SEC code.

Scenario F – Simplified Scenario G –

Pension Payments ACH Credit Payments
(with Remittance Data)
• A U.S. domiciled company makes pension payments to retirees to Foreign Receivers
residing outside the territorial jurisdiction of the United States
(expatriates) using Direct Deposit. • A foreign bank offers a service in the United States to send credit
• For some of the expatriates, the company has instructions to payments to companies or individuals in its country of domicile.
send the funds through the ACH Network to a Gateway Operator, • The credit payments and remittance data are sent to the foreign
with further instructions to send to a financial agency in a foreign bank’s U.S. correspondent via the ACH Network.
country.
• At the end of the daily processing cycle, the U.S. correspondent
• For the balance of the expatriates, when the Direct Deposit is credits the foreign bank’s correspondent account with the funds
being sent to domestic U.S. financial institutions consider the consolidated during the day and sends an EDI file with the
following questions: individual entry detail and remittance information.
– Are the funds staying in the U.S. financial institution? • The foreign correspondent bank debits the U.S. correspondent
Should be a PPD transaction bank’s account on their books and sends the credit and the
– Or are there standing instructions to send the pension payment remittance information to the receiving company.
through various means to a foreign financial agency?
Should be IAT transaction The credit transactions going to the U.S. correspondent bank
would be IAT transactions. The U.S. correspondent bank
– Are the funds co-mingled with other funds, like Social Security,
should instruct their correspondent to ensure that they format
and then sent to another country?
the transactions using the IAT SEC Code.
Should be PPD transaction

OG94 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

Scenario H – Money Transmitters: 2. 

Segregate any suspect transactions into an
A U.S.-domiciled money transmitter receives a OFAC review module or queue;
payment order from a foreign customer at one of its 3. Populate the Gateway Operator OFAC Screening
foreign branch offices to send funds to a Receiver Indicator (Field 10, IAT Entry Detail Record) for
in the U.S. The money transmitter makes a book clean transactions with “0”; (NOTE: This field
entry to record the transaction on the books of is Optional under the NACHA Operating Rules,
its offices in both countries, and creates an ACH but its use is strongly encouraged);
credit entry to send the funds to the Receiver at
the Receiver’s bank (also in the U.S.). 4. Rebalance original batch and file, if necessary
and send to ACH Operator;
Result – Domestic or IAT? 5. Investigate suspect transactions;
The resulting ACH credit to the Receiver in the
U.S. would be an IAT and not domestic because • For a suspect transaction cleared by the
the foreign money transmitter is a financial agency investigation:
that is involved in the transaction by accepting – P
 opulate the Gateway Operator OFAC
money directly from the Originator. Screening Indicator (Field 10, IAT Entry
Detail Record) for clean transactions with
“0”; (NOTE: This field is Optional under
Simplified Scenario H –
the NACHA Operating Rules, but its use is
Money Transmitters
strongly encouraged);
• A money transmitter company receives a payment order from a
customer (Originator) in a foreign branch office to send money via – B
 atch cleared transactions and send to the
the ACH to a Receiver in the United States. ACH Operator for normal processing and
• The money transmitter transfers the money via book entry to its settlement.
U.S. branch office and originates the payment to the Receiver in
the U.S. via the ACH Network. • For transactions confirmed as an OFAC hit:
The credit transaction to the U.S. Receiver would be an
– Cease processing of the entry;
IAT entry.

– N
 otify the Foreign Gateway Operator that
the debit entry has been rejected and is in
INBOUND IAT DEBIT PROCESSING violation of U.S. law.
PROCEDURES
– Notify OFAC within 10 business days
OFAC has provided NACHA with specific
requirements and expectations regarding the – P
 rovide a copy of the payment transaction
handling of inbound IAT debit transactions. Under to the RDFI and advise it that the transaction
these requirements, a Gateway Operator that destined for one of its customers has been
identifies the presence of a blocked party in an rejected.
inbound IAT debit will cease processing the entry,
and take several additional steps to report the Note: Under these processing guidelines, a
violation to OFAC, the Foreign Gateway Operator, Gateway Operator will not send IAT debits to the
and the RDFI. ACH Operator when there is a “1” in the OFAC
Screening Indicator field. All suspect transactions
ODFI/Gateway Operator Responsibilities for either will be cleared or will have their processing
Inbound IAT Debit Transactions ceased.
A financial institution acting as a Gateway Operator RDFI Responsibilities for Inbound IAT
(ODFI) for Inbound IAT debit transactions Debit Transactions
should: RDFIs should recognize that they may receive IAT
debit transactions and be prepared in advance to
1. Review all Inbound IAT debit transactions for handle the IAT debits. The RDFI for Inbound IAT
OFAC compliance, including all parties to the debit transactions should:
transaction and all remittance data;

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG95
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

Below are key issues to consider with regard

1. 
Review all incoming IAT debits for OFAC to OFAC compliance for international ACH
compliance; transactions:
2. Post clean transactions normally;
• All financial institutions are responsible for
3. Investigate any suspect IAT debits; OFAC compliance.

4. 
For a suspect transaction cleared by an • All financial institutions should have a written
investigation, post normally; OFAC compliance policy.
For a suspect transaction confirmed as an OFAC
• If a financial institution contracts with a third-
hit – contact OFAC directly. The Gateway Operator
party provider to do the actual OFAC review of
may have missed this transaction or the OFAC list
the transactions, a financial institution cannot
may have been revised. OFAC will handle these
contract away its liability for OFAC compliance.
situations on a case-by-case basis.
For additional information on OFAC
If the RDFI receives notification from the Gateway
Compliance, see Chapter Three (OFAC
Operator that a transaction has been rejected,
Requirements and Obligations) of these
this information should be included in any AML
Guidelines.
evaluation of the customer by the financial
institution. Information on rejected transactions
is being provided to the RDFI by the Gateway IAT MAPPING
Operator at the request of OFAC. The following example of Scenario F (which
is discussed earlier in this chapter) is provided
NOTE: Under these processing guidelines, an to assist ACH participants in understanding the
RDFI should not receive IAT debits in which there mapping of mandatory data elements into the IAT
is a “1” in the OFAC Screening Indicator field. addenda record structure. Complete formatting
This does not relieve the RDFI of its obligation to requirements and technical specifications for the
screen IAT debits that it receives. IAT transaction can be located within the NACHA
Operating Rules, and a chapter on mapping the full
OFAC REQUIREMENTS FOR FINANCIAL IAT format is included in the IAT Survival Guide.
INSTITUTIONS
Example: Outbound Pension/Credit Transfer
OFAC has been very clear in its expectations of
financial institutions with respect to the IAT
Scenario F – Pension Payments
entries. In a letter from R. Richard Newcomb,
Director, Office of Foreign Asset Control dated Peanut Company makes pension payments to
March 9, 2004, OFAC stated that, for Inbound 400 U.S.-resident retirees and 50 retirees residing
IAT entries, “U.S. RDFIs and beneficiaries will offshore. Twice monthly, Peanut Company sends
continue to have an obligation to ensure that all pension payment instructions for 400 retirees in a
aspects of inbound, cross-border transactions are single file to Bank of Bluemont, where it holds an
in compliance with OFAC regulations and to take account. Upon receipt of the pension information
appropriate steps to investigate, suspend, reject, from Peanut Company, Bank of Bluemont executes
block, and report on transactions as necessary.” the following payment transactions:
For Outbound IAT entries, the “U.S. ODFIs and
• Originates an ACH file of 400 credit entries to
their Originators will continue to be responsible
pay 400 U.S. retirees on settlement date, with an
for ensuring that all parties to the transactions, as
offsetting debit entry to the Peanut Company’s
well as the underlying purpose of the transactions,
account at the Bank of Bluemont for the total of
are not in violation of OFAC regulations, and they
the sum value of all 400 credit entries.
will need to take appropriate steps to investigate,
suspend, reject, block, and report on transactions.”
• For the 50 retirees residing offshore, Peanut
Company uses three payment methodologies:

OG96 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

(1) originate a direct deposit entry to the Parties to the Transaction:

pensioner’s account in the foreign country; (2)
initiate a direct deposit entry to a U.S. bank Originator: Peanut Company
account and routing number for further credit to 8916 Riverbend Road
the pensioner’s account in the foreign country; Atlanta, GA 30666
or (3) mail a check to the pensioner. Originator Identification Number:
395468717
Scenario F-1, below, illustrates the mapping of
a payment when the Originator has specific ODFI: Bank of Bluemont
information identifying the foreign financial Routing Number – 345 67 891
institution to which the Receiver’s funds are to be
Gateway Operator/RDFI: Trust Bank
directed. In some cases, an Originator may possess
Routing Number
only domestic banking information for the Receiver,
– 123 45 678
even though it knows that the funds will ultimately
flow out of the country. In still other situations, the Receiver: Susan Smith
Originator may not have sufficient information to 14 Calle de Cortez
know whether funds will flow internationally or Barcelona, Spain
not. Scenarios F-2 and F-3 illustrate how formatting Pension amount: $1,050.00
of IAT transactions would vary in these situations. Account Number: 450200051332

Scenario F-1: Foreign RDFI: BBVA

Susan Smith resides in Barcelona, Spain and 1849 Avenida de las Americas
receives her pension payments to her checking Barcelona, Spain
account at BBVA in Barcelona. Peanut Company Routing Number:
has Susan’s foreign bank information on file 9121000418450
and originates an IAT entry through a Gateway
Operator.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG97
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

ALL ENTRIES FILE HEADER RECORD

(Scenario F)

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

DATA RECORD FILE FILE IMMEDIATE

ELEMENT TYPE PRIORITY IMMEDIATE IMMEDIATE CREATION CREATION FILE ID RECORD BLOCKING FORMAT DESTINATION IMMEDIATE REFERENCE
NAME CODE CODE DESTINATION ORIGIN DATE TIME MODIFIER SIZE FACTOR CODE NAME ORIGIN NAME CODE

Field
Inclusion
Requirement M R M M M O M M M M O O O

UPPER
CASE A-Z
Contents
NUMERIC
‘1’ Numeric bTTTTAAAAC bTTTTAAAAC YYMMDD HHMM 0-9 ‘094’ ‘10’ ‘1’ Alphameric Alphameric Alphameric

Length 1 2 10 10 6 4 1 3 2 1 23 23 8

Position 01-01 02-03 04-13 14-23 24-29 30-33 34-34 35-37 38-39 40-40 41-63 64-86 87-94

BANK OF
EXAMPLE
‘1’ 01 051000033 34567891 091102 0935 A ‘094’ ‘10’ ‘1’ TCB SERVICES BLUEMONT

File Header Record – Original Entry File Creation Date and File Creation Time
The File Creation Date is ‘091102,’ the date on
Key Fields: which the file is prepared by Bank of Bluemont.
The File Creation Time is 0935, representing the
Immediate Destination time in hours and minutes that the creation or
The Immediate Destination Field identifies the exchange took place.
party to which the file is being delivered. In
Scenario F, this field contains the Routing Number File ID Modifier
of the ACH Operator – TCB Services. The File ID Modifier is ‘A’ because it is the first file
that Trust Bank is delivering to its ACH Operator
Immediate Origin (TCB Services) on November 2nd. Subsequent
The Immediate Origin Field identifies the sender files, if any, would be labeled ‘B,’ ‘C,’ etc. The File
of the file. In this example, this field contains the ID Modifier, coupled with the File Creation Date
Routing Number of the ODFI – Bank of Bluemont. and Time, can be used by the ODFI, along with
other information, to trace the file.

OG98 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

IAT COMPANY/BATCH HEADER RECORD FOR IAT ENTRIES

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
GO
FOREIGN ISO STANDARD ISO ISO IDENTIFICATION/
DATA RECORD SERVICE FOREIGN EXCHANGE FOREIGN DESTINATION ENTRY COMPANY ORIGINATING DESTINATION EFFECTIVE SETTLEMENT ORIGINATOR ORIGINATING
ELEMENT TYPE CLASS IAT EXCHANGE REFERENCE EXCHANGE COUNTRY ORIGINATOR CLASS ENTRY CURRENCY CURRENCY ENTRY DATE STATUS DFI BATCH
NAME CODE CODE INDICATOR INDICATOR INDICATOR REFERENCE CODE IDENTIFICATION CODE DESCRIPTION CODE CODE DATE (JULIAN) CODE IDENTIFICATION NUMBER
Field
Inserted by
Inclusion M M O M R R M M M M M M R M M M
ACH Operator
Requirement

Contents ‘5’ Numeric Alphameric Alphameric Numeric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric Alphameric YYMMDD Numeric Alphameric TTTTAAAA Numeric

Length 1 3 16 2 1 15 2 10 3 10 3 3 6 3 1 8 7

Position 01-01 02-04 05-20 21-22 23-23 24-38 39-40 41-50 51-53 54-63 64-66 67-69 70-75 76-78 79-79 80-87 88-94

Example ‘5’ 200 FF 3 ES 395468717 IAT PENSION USD USD 091103 1 34567891 0000001

Company/Batch Header Record – In this example, the Originator Identification Field

Original Entry contains the Originator’s (Peanut Company’s)
Taxpayer Identification Number.
Key Fields:
Standard Entry Class Code
Originator Identification The SEC Code distinguishes the various types
The Originator Identification field carries the of ACH Entries. In this example, the SEC Code
Originator’s unique identification number. In is ‘IAT’ because flow of funds and the payment
the case of IAT Entries where the Originator is instructions are destined to a financial institution
not a natural person, this field must contain the outside the United States.
IRS Taxpayer Identification Number (TIN) of the Company Entry Description
Originator identified in the Originator Name Field.
The Company Entry Description provides a
For an Originator that is not a natural Person, this
description of the entry that is displayed on the
field must contain the IRS Taxpayer Identification
employee’s statement when the payment is posted.
Number (TIN) of the Originator identified in the
In this example, Peanut Company has identified
Originator Name Field. For an Originator that
this transaction as a pension payment.
is not a natural Person and is not established or
organized under the laws of a State or the United Effective Entry Date
States, this field must contain the account number The Effective Entry Date is the date specified
belonging to the Originator (as identified in the by Peanut Company as the day on which its
Originator Name field) at the foreign financial pensioners should be paid.
institution. If this number exceeds 9 characters,
this field must contain the last 9 characters of the Settlement Date
account number belonging to the Originator at the The Settlement Date ( Julian Date) is the date on
foreign financial institution. If the foreign account which the ODFI and RDFI are debited or credited
number contains 9 or fewer characters, the entire by the Federal Reserve. The Settlement Date is
account number must be utilized. inserted by the ACH Operator and, therefore, is
left blank in this example. Assuming that the file
The Originator Identification may be preceded is delivered appropriately on November 2, the
by a one-digit alphameric code, as established Settlement Date for this batch would be ‘307,’ the
between the ODFI and the Originator, for further Julian Date equivalent for November 3rd.
identification of the Originator to the ODFI. When
used, this code must appear in the first position of GO Identification/Originating DFI Identification
this field, followed by the Originator Identification, The GO/Originating DFI Identification field carries
as defined above. Bank of Bluemont’s Routing Number.

When the ODFI has a contractual relationship with ISO Destination Country Code, ISO Originating
a Third-Party Sender rather than the Originator Currency Code, and ISO Destination Currency
itself, the value of this field may identify either the Code
Originator or the Third-Party Sender. Refer to the International Organization for
Standardization’s website at www.iso.org for ISO
currency and country code values.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG99
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

IAT ENTRY DETAIL RECORD

FIELD 1 2 3 4 5 6 7 8 9 10 11 12 13

FOREIGN
RECEIVER’S GATEWAY
GO NUMBER ACCOUNT OPERATOR SECONDARY
DATA RECORD IDENTIFICATION/ OF NUMBER/ OFAC OFAC ADDENDA
ELEMENT TYPE TRANSACTION RECEIVING DFI CHECK ADDENDA DFI ACCOUNT SCREENING SCREENING RECORD TRACE
NAME CODE CODE IDENTIFICATION DIGIT RECORDS RESERVED AMOUNT NUMBER RESERVED INDICATOR INDICATOR INDICATOR NUMBER

Field
Inclusion M M M M M N/A M M N/A O O M M
Requirement

Contents ‘6’ Numeric TTTTAAAA Numeric Numeric Blank $$$$$$$$¢¢ Alphameric Blank Alphameric Alphameric Numeric Numeric

Length 1 2 8 1 4 13 10 35 2 1 1 1 15

Position 01-01 02-03 04-11 12-12 13-16 17-29 30-39 40-74 75-76 77-77 78-78 79-79 80-94

34567891
EXAMPLE
‘6’ 22 12345678 0 0007 0000105000 450200051332 1 0000367

Entry Detail Record – Original Entry Gateway Operator OFAC Screening Indicator
Key Fields: This field indicates the results of a Gateway
Operator screen for OFAC compliance. A value of
Transaction Code ‘0’ indicates that the Gateway Operator has not
found a potential blocked party, as identified by
The transaction code is used to direct the payment
OFAC on its list of Specially Designated Nationals
to a specific type of account (i.e., checking, savings,
(SDN list). A value of ‘1’ indicates the potential
loan, or general, ledger) and indicates whether the
presence of a blocked party. On an Outbound IAT
payment is a debit or credit. In this example, a
Entry, this field will be left blank.
‘22’ indicates a credit to the pensioner’s checking
account.
Trace Number
GO Identification/Receiving DFI Identification The Trace Number is assigned by the ODFI in
ascending sequence and uniquely identifies
For Outbound IAT Entries, this field contains the
each entry within a batch. The first eight digits
Routing Number of the U.S. Gateway Operator.
of the Trace Number are always the Routing
In this example, this field contains the routing
Number of the Gateway Operator/ODFI entering
number of Trust Bank, which is acting as the
the transaction into the Network. In association
Gateway Operator.
with the File Creation Date, File ID Modifier,
and other information, the Trace Number can be
Foreign Receiver’s Account Number/
used to trace an entry through the ACH Network.
DFI Account Number
Throughout the entire processing cycle (from GO/
For Outbound IAT Entries, this field contains ODFI to RDFI), the Trace Number is retained with
the foreign Receiver’s account number. In this the entry record. The Trace Number is critical in
example, this field contains Susan Smith’s account routing return entries and notifications of change
number at BBVA in Spain, ‘450200051332.’ back to the ODFI through the ACH Network.

Amount
This field contains the dollar amount of the entry in
U.S. dollars.

OG100 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

FIRST IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

DATA RECEIVING COMPANY ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE TRANSACTION TYPE FOREIGN PAYMENT FOREIGN TRACE NAME/INDIVIDUAL SEQUENCE
NAME CODE CODE CODE AMOUNT NUMBER NAME RESERVED NUMBER

Field
Inclusion M M R R O M N/A M
Requirement

Contents ‘7’ ‘10’ Alphameric $$$$$$$$$$$$$$$$¢¢ Alphameric Alphameric Blank Numeric

Length 1 2 3 18 22 35 6 7

Position 01-01 02-03 04-06 07-24 25-46 47-81 82-87 88-94

Example ‘7’ ‘10’ PEN 000000000000105000 SUSAN SMITH 0000367

First IAT Addenda Record – Original Entry Receiving Company Name/Individual Name
This field contains the name of the Receiver. In
Key Fields: this example, this field identifies the pensioner,
Susan Smith.
Transaction Type Code
This field contains a three-character code used to Entry Detail Sequence Number
identify the type of transaction. In this example, This field contains the ascending sequence number
this field contains ‘PEN’ to identify a pension section of the Entry Detail Record’s trace number.
payment. This number is the same as the last seven digits
of the trace number of the related Entry Detail
Foreign Payment Amount Record. In this example, the entry detail sequence
For Outbound IAT Entries originated using a Foreign number is ‘0000367.’
Exchange Indicator of “FV” (fixed-to-variable), this
field is zero-filled. For Outbound IAT Entries using
a Foreign Exchange Indicator of “VF” (variable-to-
fixed) or “FF” (fixed-to-fixed), this field contains
the amount for which the entry is to be received by
the Foreign Receiver in the currency denomination
expressed in the ISO Destination Currency Code
Field of the Company/Batch Header Record. In
this fixed-to-fixed example, this is the amount of
the credit to Susan Smith’s account in US dollars.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG101
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

SECOND IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE NAME STREET ADDRESS RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘11’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

Example ‘7’ ‘11’ PEANUT COMPANY 8916 RIVERBEND ROAD 0000367

THIRD IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE ORIGINATOR ORIGINATOR SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE COUNTRY & POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘12’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

Example ‘7’ ‘12’ ATLANTA*GA\ US*30666\ 0000367

Second and Third IAT Addenda Records – the backslash should immediately follow the last
Original Entry known data element (e.g., ‘ATLANTA\’). When the
missing data element occurs before another data
Key Fields:
element — in this example, if the city were not
available — an asterisk should be used as a place
Originator Name
holder for the missing data element, followed by
This field contains the name of the Originator of
the next data element (e.g., ‘*GA\’.)
the transaction, Peanut Company.
Originator Country and Postal Code
Originator Street Address
This field identifies Peanut Company’s country
This field contains Peanut Company’s physical
and postal code, ‘US*30666\’. Data elements must
street address, ‘8916 Riverbend Road.’
be separated by an asterisk and must end with a
backslash.
Originator City and State or Province
This field contains the city and, if applicable, the Note: Where the country is known but the postal
state or province of the Originator. Asterisks must code is unavailable, the country should appear,
be used to separate the data elements, and the last immediately followed by a backslash (e.g., ‘US\’).
data element must be followed by a backslash. Where the country is not available but the postal
This example identifies ‘ATLANTA*GA\’ for the city code is present, an asterisk should be used as a
and state in which Peanut Company is located. place holder, followed by the postal code and
backslash (e.g., ‘*30666\’).
Note: In some cases, a defined data element may
be unknown or may not be applicable. When
the missing data element occurs last — in this
example, if no state or province were available —

OG102 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

FOURTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

ORIGINATING DFI ORIGINATING

DATA ORIGINATING IDENTIFICATION ORIGINATING DFI ENTRY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE DFI NUMBER DFI BRANCH SEQUENCE
NAME CODE CODE NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘13’ Alphameric Alphameric Alphameric Alphameric Blank Numeric

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

Example ‘7’ ‘13’ BANK OF BLUEMONT 01 34567891 US 0000367

Fourth IAT Addenda Records – Originating DFI Identification

Original Entry
For Outbound IAT Entries, this field contains the
Key Fields: routing number of the US ODFI. In this example, the
Bank of Bluemont’s routing number is ‘34567891.’
Originating DFI Name
Originating DFI Branch Country Code
On an Outbound IAT entry, this field contains the
name of the US ODFI, Bank of Bluemont. This field contains a 2-digit code, as approved by
the International Organization for Standardization,
Originating DFI Identification Number Qualifier used to identify the country in which the branch
of the bank that originated the entry is located.
This field contains a 2-digit code that identifies the
On an Outbound IAT Entry, this field will
numbering scheme used in the Originating DFI
contain ‘US.’
Identification Number Field. In this example, ‘01’
identifies that the numbering scheme used for the
Bank of Bluemont as a National Clearing System
Number.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG103
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

FIFTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6 7 8

RECEIVING RECEIVING
DATA RECEIVING DFI IDENTIFICATION DFI ENTRY DETAIL
ELEMENT RECORD TYPE ADDENDA TYPE DFI NUMBER RECEIVING DFI BRANCH SEQUENCE
NAME CODE CODE NAME QUALIFIER IDENTIFICATION COUNTRY CODE RESERVED NUMBER

Field
Inclusion M M M M M M N/A M
Requirement

Contents ‘7’ ‘14’ Alphameric Alphameric Alphameric Alphameric Blank Numeric

Length 1 2 35 2 34 3 10 7

Position 01-01 02-03 04-38 39-40 41-74 75-77 78-87 88-94

Example ‘7’ ‘14’ BBVA 03 9121000418450 ES 0000367

Fifth IAT Addenda Record – Original Entry Receiving DFI Identification

This field contains the bank identification number
of the DFI at which the Receiver maintains his
Key Fields: account. For Outbound IAT Entries, this field
contains the bank identification number of the
Receiving DFI Name foreign RDFI. In this example, BBVA’s bank
This field contains the name of the Receiving DFI identification number is ‘9121000418450.’
holding the Receiver’s account. In an Outbound
IAT Entry, this field will identify the name of the Receiving DFI Branch Country Code
foreign RDFI - in this example, BBVA. This field contains a 2-digit code, as approved by
the International Organization for Standardization,
Receiving DFI Identification Number Qualifier used to identify the country in which the branch of
This field contains a 2-digit code that identifies the bank that receives the entry is located. In this
the numbering scheme used in the Receiving example, ‘ES’ identifies Spain as the location of the
DFI Identification Number Field. In this example, BBVA branch at which Susan Smith’s account is
‘03’ identifies BBVA’s identification number as an located.
IBAN.

OG104 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

SIXTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA RECEIVER ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE IDENTIFICATION RECEIVER SEQUENCE
NAME CODE CODE NUMBER STREET ADDRESS RESERVED NUMBER

Field
Inclusion M M O M N/A M
Requirement

Contents ‘7’ ‘15’ Alphameric Alphameric Blank Numeric

Length 1 2 15 35 34 7

Position 01-01 02-03 04-18 19-53 54-87 88-94

Example ‘7’ ‘15’ SM18362-28 14 CALLE DE CORTEZ 0000367

SEVENTH IAT ADDENDA RECORD

FIELD 1 2 3 4 5 6

DATA ENTRY DETAIL

ELEMENT RECORD TYPE ADDENDA TYPE RECEIVER RECEIVER SEQUENCE
NAME CODE CODE CITY & STATE/PROVINCE COUNTRY & POSTAL CODE RESERVED NUMBER

Field
Inclusion M M M M N/A M
Requirement

Contents ‘7’ ‘16’ Alphameric Alphameric Blank Numeric

Length 1 2 35 35 14 7

Position 01-01 02-03 04-38 39-73 74-87 88-94

Example ‘7’ ‘16’ BARCELONA\ ES*28001\ 0000367

Sixth and Seventh IAT Addenda Records – Receiver City and State or Province
Original Entry This field contains the city and, if applicable, the
state or province of the Receiver. Asterisks must
Key Fields: be used to separate the data elements, and the last
data element must be followed by a backslash.
Receiver Identification Number This example identifies ‘BARCELONA\’ as the city
This field may be used by the Originator to insert its in which Susan Smith resides. In this example, no
own number for tracing purposes. In this example, province is indicated for the city of Barcelona.
“SM18362-28” is Susan Smith’s identification
number at Peanut Company. Receiver Country and Postal Code
This field identifies Susan Smith’s country code,
Receiver Street Address ‘ES*28001\’.
This field contains the Receiver’s (Susan Smith’s)
physical street address, ‘14 CALLE DE CORTEZ.’

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG105
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

ALL ENTRIES COMPANY/BATCH CONTROL RECORD (F)

FIELD 1 2 3 4 5 6 7 8 9 10 11

DATA RECORD SERVICE ENTRY/ TOTAL DEBIT TOTAL CREDIT MESSAGE

ELEMENT TYPE CLASS ADDENDA ENTRY ENTRY DOLLAR ENTRY DOLLAR COMPANY AUTHENTICATION ORIGINATING DFI BATCH
NAME CODE CODE COUNT HASH AMOUNT AMOUNT IDENTIFICATION CODE RESERVED IDENTIFICATION NUMBER

Field
Inclusion
Requirement M M M M M M R O N/A M M

Contents ‘8’ Numeric Numeric Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Alphameric Alphameric Blank TTTTAAAA Numeric

Length 1 3 6 10 12 12 10 19 6 8 7

Position 01-01 02-04 05-10 11-20 21-32 33-44 45-54 55-73 74-79 80-87 88-94

Example ‘8’ 200 0000008 0012345678 000000000000 000000105000 395468717 34567891 0000367

Company/Batch Control Record – Total Debit and Credit Entry Dollar Amounts
Original Entry The Total Debit and Credit Entry Dollar Amount
fields contain accumulated Entry Detail debit and
Key Fields: credit totals within a given batch. In this example,
the Total Credit Entry Dollar Amount is $1050.00,
Entry/Addenda Count and the Total Debit Entry Dollar Amount is $0.00
The Entry/Addenda Count Field is a tally of each because no debits were originated within the
Entry Detail and Addenda Record processed within batch.
the batch. In this example, one Entry Detail Record
and seven Addenda Records were used. Company Identification
This field conveys the same information that is
Entry Hash contained within the Originator Identification
This field is prepared by hashing the 8-digit Field of the Company/Batch Header Record.
Routing Number in each entry. The Entry Hash
provides a check against inadvertent alteration of Originating DFI Identification
data contents due to hardware or program failure. The Originating DFI Identification Field carries
the same information that is carried in the GO
Identification/Originating DFI Identification Field
of the Company/Batch Header Record.

OG106 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

ALL ENTRIES FILE CONTROL RECORD (F)

FIELD 1 2 3 4 5 6 7 8

DATA TOTAL DEBIT ENTRY TOTAL CREDIT ENTRY

ELEMENT RECORD TYPE ENTRY/ADDENDA DOLLAR AMOUNT DOLLAR AMOUNT
NAME CODE BATCH COUNT BLOCK COUNT COUNT ENTRY HASH IN FILE IN FILE RESERVED

Field
Inclusion
Requirement M M M M M M M N/A

Contents ‘9’ Numeric Numeric Numeric Numeric $$$$$$$$$$¢¢ $$$$$$$$$$¢¢ Blank

Length 1 6 6 8 10 12 12 39

Position 01-01 02-07 08-13 14-21 22-31 32-43 44-55 56-94

EXAMPLE ‘9’ 000001 000002 00000008 0012345678 000000000000 000000105000

File Control Record – Original Entry Total Debit and Credit Dollar Amount in File
The Total Debit and Credit Entry Dollar Amounts
Key Fields: Fields contain accumulated Entry Detail debit and
credit totals within the file. In this example, the
Batch Count
Total Debit Entry Dollar Amount is $0.00, and the
The value of the Batch Count Field is equal to the Total Credit Entry Dollar Amount is $1050.00.
number of Company/Batch/Header Records in the
file. In this example, the value is ‘1.’

Entry Hash
This field is prepared by hashing the RDFI’s 8-digit
Routing Number in each entry. The Entry Hash
provides a check against inadvertent alteration of
data contents due to hardware or program failure.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG107
SECTION V – Standard Entry Class Codes
C H A P T E R 4 3   I N T E R N AT I O N A L A C H PAY M E N T S

Scenario F-2 • Receiving DFI Identification Number Qualifier –

Susan Smith resides in Barcelona, Spain. Peanut This field contains ‘01’ to identify BBVA Miami’s
Company knows that Susan’s pension funds will be identification number as National Clearing
moved internationally and formats the transaction Number (US routing number) rather than BBVA
as an IAT entry. However, Susan’s banking Spain’s national clearing system number.
information on file with Peanut Company identifies
a domestic account at BBVA in Miami. BBVA has • Receiving DFI Identification – This field contains
a standing instruction from Susan (separate from the bank identification number of the DFI at
the IAT transaction) to further credit the funds to which the Receiver maintains his account. For
her BBVA account in Barcelona through a book Outbound IAT Entries, this field contains the
entry transfer. bank identification number of the foreign RDFI.
In this example, this field is populated with
In this model, the mapping of the payment BBVA Miami’s routing number.’
information is identical to the mapping of Susan’s
payment in Scenario F-1, above, with the following • Receiving DFI Branch Country Code – This field
exceptions: is populated with the value ‘US’ to identify the
United States as the country in which the RDFI,
IAT Company/Batch Header Record BBVA Miami, is located.
The values of the fields within the Company/
Note: For Scenario F-2, the contents of all other
Batch Header Record remain unchanged from
records comprising the IAT Entry (Addenda
those defined earlier for Scenario F-1. In this
Records 1-4, 6, and 7) remain unchanged from
scenario, the ISO Destination Country Code is also
those illustrated in Scenario F-1.
populated with ‘ES’ because the Originator knows
that the funds will ultimately be forwarded to a
Scenario F-3
Receiving DFI located in Spain.
Susan Smith, who resides in Barcelona, Spain,
has requested that Peanut Company deposit her
IAT Entry Detail Record
pension funds into a domestic bank account at
• GO/Receiving DFI Identification – BBVA Miami’s BBVA in Miami. Susan’s address on record with
routing number (rather than Trust Bank’s) is Peanut Company is a foreign one, and Peanut
identified within this field. Company does not know whether or not Susan’s
funds will be moved out of the country. Peanut
• Check Digit – The check digit for BBVA Miami’s
Company could (1) contact Susan and confirm
routing number (rather than Trust Bank’s) is
whether she intends for the funds to remain at an
identified within this field.
account in the U.S. or whether she plans to transfer
the money to an account in Spain, or (2) format
• Foreign Receiver’s Account Number/DFI
the entry as an IAT transaction. In this example,
Account Number – This field contains a
Peanut Company has chosen to err on the side of
domestic account number at BBVA Miami
caution and code the transaction as an IAT entry to
rather than Susan’s BBVA account number in
ensure its compliance with OFAC sanctions policies.
Barcelona, Spain.
The mapping of the IAT payment information is
identical to the earlier mapping of Susan’s payment
Fifth IAT Addenda Record in Scenario F(1), with the following exceptions:
• Receiving DFI Name – This field contains the
name of the Receiving DFI holding the Receiver’s IAT Company/Batch Header Record
account. In Scenario F-2, this field identifies the
• ISO Destination Country Code – In Scenario F-3,
name of the domestic RDFI (BBVA Miami) rather
the ISO Destination Country Code would be
than BBVA in Spain.
populated with the value ‘US.’

OG108 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 44  POINT OF PURCHASE ENTRIES

IAT Entry Detail Record

CHAPTER 44
• GO/Receiving DFI Identification – BBVA Miami’s
routing number (rather than Trust Bank’s) is Point of Purchase Entries (POP)
identified within this field.

• Check Digit – The check digit for BBVA Miami’s A Point of Purchase Entry (POP) is a Single-Entry
routing number (rather than Trust Bank’s) is ACH debit originated based on an eligible source
identified within this field. document provided to an Originator by a Receiver
at the point-of-purchase or manned bill payment
• Foreign Receiver’s Account Number/DFI location for conversion at that location. This
Account Number – This field contains a application provides Originators with an alternative
domestic account number at BBVA Miami to processing Receivers’ checks as the method of
rather than Susan’s BBVA account number in payment. This chapter addresses issues relating to
Barcelona, Spain. the origination and receipt of POP Entries.

Fifth IAT Addenda Record POP entries are considered to be ACH entries
from start to finish, with the Receiver’s check used
• Receiving DFI Name – This field contains the
by the Originator solely as a source document
name of the Receiving DFI holding the Receiver’s
for the Receiver’s routing and account number
account. In Scenario F-2, this field identifies the
information. Such transactions are not considered
name of the domestic RDFI (BBVA Miami) rather
to be truncated checks and do not fall under
than BBVA in Spain.
the requirements of check law or the Uniform
Commercial Code for the following reasons:
• Receiving DFI Identification Number Qualifier –
This field contains ‘01’ to identify BBVA Miami’s
1. the check is not accepted by the merchant as a
identification number as National Clearing
negotiable instrument; and
Number (US routing number) rather than BBVA
Spain’s IBAN.
2. the check is not negotiated by the merchant or
accepted into the check collection system.
• Receiving DFI Identification – This field contains
the bank identification number of the DFI at
which the Receiver maintains his account. For INITIATING A POP ENTRY ­—
Outbound IAT Entries, this field contains the AN OVERVIEW
bank identification number of the foreign RDFI. • An Originator provides notice that a check
In this example, this field is populated with received for payment will be converted to an
BBVA Miami’s routing number.’ electronic funds transfer.

• Receiving DFI Branch Country Code – This field • To initiate a POP entry, the Receiver must present
is populated with the value ‘US’ to identify the an eligible source document (check) that has
United States as the country in which the RDFI, not been previously voided or negotiated to the
BBVA Miami, is located. Originator at time of payment, usually at a cash
register or other checkout location.
Note: For Scenario F-3, the contents of all other
records comprising the IAT Entry (Addenda – The check need not be completed or signed
Records 1-4, 6, and 7) remain unchanged from by the Receiver.
those illustrated in Scenario F-1.
• The Originator must use a check reading device
to capture MICR information from the check
(i.e., routing number, account number, and
serial number), which is used by the Originator

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG109
SECTION V – Standard Entry Class Codes
CHAPTER 44  POINT OF PURCHASE ENTRIES

to generate a debit entry to the Receiver’s OBLIGATIONS OF ORIGINATORS

account. The Originator may not key enter the
Agreements with ODFIs
MICR information from the check, nor may the
Originator key enter the MICR information after Originators choosing to utilize the ACH Network
the check reader has captured this data, except for initiating POP transactions should consider
due to a misread or capture error. modifications to their agreements with their ODFIs
to address the origination of these entries.
• The Originator then key enters the amount of
the transaction. These modifications could, for example, address
the extent to which the Originator and ODFI share
• An authorization is provided to the Receiver liability for the following warranties as they apply
to sign, authorizing the debit to the Receiver’s to the origination of POP entries:
account.
• The Originator must initially use a reading
• The Originator must provide to the Receiver (1) device to capture the Receiver’s routing number,
the source document, which the Originator has account number, and check serial number from
voided, (2) a copy of the authorization, and (3) a the MICR line of the Receiver’s eligible source
receipt containing specific information relating document.
to the purchase.
– Such information may not be key-entered by
the Originator except to correct errors from
SOURCE DOCUMENTS
MICR misreads or processing rejects.
Originators may accept a check as an eligible
source document for a POP debit entry only if the • The Originator must void the eligible source
check is presented at the point-of-purchase or a document at the time of the transaction and
manned bill payment location. return it to the Receiver.

The Rules governing POP entries define specific – The source document may not have been used
eligibility requirements and limits on the types of for a prior POP entry.
source documents that may be converted.
• The Originator must retain the original or a copy
For a detailed list of eligibility criteria for of the Receiver’s authorization for two years
check conversion entries, refer to the Source from the Settlement Date of the POP entry.
Document Eligibility Charts in Appendix E of
these Guidelines, or to the definition of Eligible – Upon receipt of an RDFI’s written request, the
Source Document in Article Eight of the Rules. ODFI must provide such copy to the RDFI
within ten banking days. Originators must
ACH DATA SECURITY REQUIREMENTS be prepared to provide such copies to their
The NACHA Operating Rules impose specific data ODFIs for this purpose.
security requirements for all ACH transactions that
involve the exchange or transmission of banking • The Originator must provide the Receiver a
information (which includes, but is not limited to, receipt containing the following information for
an entry, entry data, a routing number, an account each POP entry to the Receiver’s account.
number, and a PIN or other identification symbol)
1.  Originator name
via an Unsecured Electronic Network.
2. Company/third-party service provider phone
ACH participants must abide by these
number for inquiries
requirements which are discussed in detail in
Chapter 4 of these Guidelines.
3.  date of transaction

OG110 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 44  POINT OF PURCHASE ENTRIES

4.  transaction amount check is used solely as a source document for

capturing the Receiver’s routing number, account
5. 
check serial number of the eligible source number, and check serial number for the entry.
document The rules governing POP incorporate Regulation
E safe harbor language into the required notice,
6. 
merchant number (or other unique requiring that the notice include the following, or
number that identifies the location of the substantially similar, language:
transaction)
“When you provide a check as
7.  terminal city payment, you authorize us either to use
information from your check to make a
8.  terminal state one-time electronic fund transfer from
your account or to process the payment
• The Rules do not require, but it is strongly as a check transaction.”
recommended, that the Originator also provide
the following information on the receipt The Originator must post the notice in a prominent
provided to the Receiver: and conspicuous location and a copy of such
notice, or similar language, must be provided to
9.  merchant address the Receiver a the time of the transaction.

10.  merchant identification number At the Originator’s discretion, the receipt and the
authorization required for POP Entries may be
11. 
Receiver’s financial institution routing provided to the Receiver on the same document or
number on different documents

12.  Receiver’s truncated account number Note: Originators should be aware that some
Receivers may choose to opt out of check conversion
13.  Receiver’s truncated identification number activity by declining to sign a written authorization
at the point of purchase. In other cases, Receivers
  – The Originator must not place the Receiver’s may have chosen to opt out of check conversion
complete account number or complete activity by having their checks reprinted to include
identification number on the receipt an Auxiliary On-Us Field in the MICR line. In both
of these situations, Originators may not convert
14.  Transaction reference number the check to a POP entry and are encouraged to
work with these customers to establish alternative
• The Originator must employ commercially payment methods.
reasonable methods to securely store all banking
information relating to POP entries.
Collection of Return Fees
For more information on agreements, refer to An Originator desiring to use the ACH Network
Chapter 15 within these Guidelines. to collect a Return Fee from a Receiver must
originate a separate Return Fee Entry using the
appropriate Standard Entry Class Code and must
Authorization/Notification Requirements
follow all rules governing the origination of Return
Originators are required to provide notice to the Fee Entries. For specific information on Return Fee
Receiver and to obtain a written authorization Entries, please refer to Chapter 54 in the Special
from the Receiver to satisfy the authorization Topics section of these Guidelines.
requirement for a POP entry. The provision of
the notice by the Originator to the Receiver, Originators need to be aware that the requirements
the receipt of the source document and the of the NACHA Operating Rules regarding the
written authorization from the Receiver together origination of Return Fee Entries are in addition to
constitute authorization for the POP entry. The

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG111
SECTION V – Standard Entry Class Codes
CHAPTER 44  POINT OF PURCHASE ENTRIES

any requirements required by applicable state law leftmost position of the Check Serial Number field,
governing Return Fees. Originators are responsible and any unused spaces within the field must be
for determining what the applicable state laws are, left blank.
if any, for each of their check-accepting locations
that intend to, or may, use the POP application. Thus, for check number 1234:

In addition, the authorization for the conversion CORRECT 1234

of the check does not include authorization for
any Return Fee Entry that may become necessary INCORRECT 0001234
to collect the check unless the authorization 000000000001234
specifically includes appropriate language covering
CK# 001234
such fees.
CK1234
Formatting Requirements 1234 6532986002
Dollar Amount CK1234 48832817
POP entries must be originated for amounts of
$25,000 or less. The NACHA Operating Rules require RDFIs to
print the check serial number on both consumer
Company Name and business Receiver’s bank statements.
Originators must ensure that the name of the
Originator appears within the Company Name Individual Name/Receiving Company Name
Field of the Company/Batch Header Record of the For POP entries, the inclusion of information in
POP entry. The contents of this field are provided the Individual Name/Receiving Company Name
to the Receiver for descriptive purposes by the Field of the POP Entry Detail Record is optional. If
RDFI, and must be formatted in such a manner that the Originator chooses to utilize this field, it must
the Receiver can easily recognize the Originator of include either:
the payment (e.g., a trading as or doing business
as name, etc.). Originators should be aware that 1. the Receiver’s name, or
the Receiver looks for a familiar name to identify
the transaction; if the Receiver does not recognize 2. 
a reference number, identification number,
the Company Name as presented on his statement, or code that the merchant uses to identify a
the Receiver may instruct his RDFI to return the particular transaction or customer.
transaction as unauthorized.
Note: When a reference number, identification
Check Serial Number number, or code is used to identify the transaction
or customer, it should be uniquely related to the
The rules governing POP entries require that the
individual or transaction. A generic description is
Originator ensure that the check serial number
not an acceptable means to identify the Receiver
from the Receiver’s source document is placed
or transaction.
within the Check Serial Number Field of the POP
Entry Detail Record. The NACHA Operating Rules
permit Originators to place only the check serial Terminal City/Terminal State
number within the Check Serial Number Field of The NACHA Operating Rules and Regulation
the POP Entry Detail Record. That is, the word E require the inclusion of terminal location
“check,” abbreviations such as “ck” or “chk,” or information on the Receiver’s monthly bank
other merchant codes must not be included within account statement for POP entries. Originators
the field. Because the Check Serial Number Field must ensure that they include a four-character name
is defined as an alphameric one, the NACHA or abbreviation of the city and a two-character
Operating Rules require information within this abbreviation for the state in which the electronic
field to be left justified and space filled. That is, terminal is located within the Terminal City Field
the serial number of the check must begin in the and within the Terminal State Field, respectively,

OG112 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 44  POINT OF PURCHASE ENTRIES

of the POP Entry Detail Record. This information In these three circumstances, the RDFI requires the
is used to identify the location of the electronic Receiver to sign or similarly authenticate a written
terminal used to originate the POP entry. statement of unauthorized debit prior to being re-
credited for the transaction.
Return of Point of Purchase Entries
POP entries are governed by the same Return Returns for Improper Source Documents or
Reasons and Return Reason Codes as other ACH When Both POP Entry and Source Document
debit entries. Have Been Presented
With respect to POP entries based on improper
A complete listing of Return Reason Codes source documents or where both the POP entry
can be found in Appendix Four of the NACHA and the source document have been presented
Operating Rules. for payment, an RDFI may return such entries in
either of two ways:
In addition, some special circumstances can apply,
as described below. 1. An RDFI (rather than the Receiver) determines
that a POP entry was based on an improper
Return by ACH Operator source document, or that the entry and the
POP entries are limited to dollar amounts of source document were both presented for
$25,000 or less. Any POP entry originated in an payment, may return the entry using Return
amount greater than $25,000 will be returned by Reason Code, R39 (Improper Source Document/
the ACH Operator. Source Document Presented for Payment).
Entries returned using this return reason code
Return by RDFI must be received by the RDFI’s ACH Operator’s
deposit deadline for the return entry to be made
POP entries, like other ACH transactions, may be
available to the ODFI no later than opening of
returned for a variety of reasons.
business on the second banking day following
the Settlement Date of the original entry.
Timing of Returns
Most POP entries need to be returned by the RDFI • No written statement of unauthorized debit is
so that the return entry is made available to the required for this code.
ODFI no later than the opening of business on the
second banking day following the Settlement Date 2. When the Receiver (rather than the RDFI) as
of the POP entry. discussed above, determines that the source
document to which an POP entry relates was
In the following circumstances, an RDFI may also improper or that the entry and the source
return a POP entry so that it is made available to document were both presented for payment,
the ODFI by opening of business on the banking the RDFI may return the entry so that it is
day following the sixtieth calendar day following made available to the ODFI by the opening of
the Settlement Date of the original entry for the business on the banking day following the 60th
following reasons: calendar day following the Settlement Date of
the original entry using Return Reason Code
1. no notice was provided to the Receiver that the R10 or R37, respectively.
check was going to be converted to an ACH
debit; • A written statement of unauthorized debit
is required when using this return reason
2. the source document used for the entry was not code.
an eligible source document; or
Originators should be aware, however, that RDFIs
3. the source document was presented for payment can not return POP entries based on a Receiver’s
as a check through the check collection claim that his authorization had been revoked
system.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG113
SECTION V – Standard Entry Class Codes
C H A P T E R 4 5   P R E A R R A N G E D PAY M E N T A N D D E P O S I T E N T R I E S

(R07) since these are one-time transactions where Reinitiation of POP Entries
the Originator generally processes the transactions POP entries that have been returned for insufficient
immediately after the purchase is complete. or uncollected funds may be reinitiated up to two
times following the return of the original entry,
As appropriate, the Receiver may (1) request his provided such reinitiations are transmitted by the
RDFI to stop the payment of a POP entry (Return Originator (or its ODFI on the Originator’s behalf)
Reason Code R08), (2) request his RDFI to return within 180 days of the settlement date of the
an unauthorized (R10) or ineligible/improper POP original entry.
entry (Return Reason Code R10 or R39), or (3) go
directly to the Originator (merchant) to request a For POP entries returned for any other reason, the
refund of the transaction. Originator must first remedy the reason for the
return before reinitiating the transaction within
Originators should also be aware that, because the 180-day time period discussed above.
the POP entry application does not require the
Originator to capture the Receiver’s name for Verification of Receiver’s Identity
inclusion on the point of purchase entry, the
The NACHA Operating Rules are silent on the
RDFI must rely on the ODFI’s warranty regarding
means by which an Originator establishes the
the validity of the Receiver’s account number for
identity of the checkwriter for a POP entry. Most
posting purposes. The RDFI, therefore, may not
retailers, merchants and other parties who accept
return a point of purchase entry using Return
checks have established policies and procedures
Reason Codes R03 or R17 solely because the
for accepting checks to limit their risk; for example,
Receiver’s name is not included in the entry. The
they use commercially reasonable procedures to
RDFI may, however, use these Return Reason
do so.
Codes if otherwise appropriate.
For a discussion on the concept of commercially
Originators must be prepared to handle returned
reasonable standards, please refer to Chapter
POP Entries and must establish procedures that
4 of these Guidelines.
enable them to identify and contact the Receiver
relating to any unpaid debit entry. Because the
Retailers, merchants and other parties normally
Originator does not retain the Receiver’s voided
continue to use standard policies and procedures
check that was used as a source document, and
when using a check for a source document.
because the Receiver’s name and address are not
Originators should be mindful that they will
included as part of the MICR-capture process,
not have the original check (source document)
Originators needs to develop alternative methods
available should the item be returned, nor will
for retaining information necessary to identify
they have a copy or image of the check unless they
the Receiver for whom a POP debit has been
choose to make such a copy or image. NACHA
returned.
Operating Rules do not require that the Originator
copy or image the check; the decision to do so is
Stop Payments left to the Originator.
As with other Single-Entry ACH transactions, a
Receiver desiring to place a stop payment order on
a POP entry may do so, provided that he notifies
his RDFI in such a time and manner that allows the
CHAPTER 45
RDFI a reasonable opportunity to act on the stop
payment order prior to acting on the debit entry. Prearranged Payment and
POP entries returned by the RDFI as payment
Deposit Entries (PPD)
stopped will bear the Return Reason Code R08 and
will be made available to the ODFI by opening of
business on the second banking day following the A Prearranged Payment and Deposit (PPD) Entry is
settlement date of the POP entry. a credit or debit entry originated by an organization
to a consumer’s account, based on standing or

OG114 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 5   P R E A R R A N G E D PAY M E N T A N D D E P O S I T E N T R I E S

single-entry authorization from that consumer. PPD respect to formatting requirements, processing
entries can be used for both recurring and non- obligations, warehousing, and timing.
recurring payments, and comprise a fundamental
component of the ACH Network. This application For more detailed information on agreements
is used for the majority of consumer payments, between Originators and their ODFIs, refer to
incorporating a large variety of Direct Deposit and Chapter 15 within these Guidelines.
Direct Payment applications within its scope.
AUTHORIZATION REQUIREMENTS
Direct Deposit is a credit application that transfers
As with any ACH transaction, the Originator must
funds into a consumer’s account at his financial
obtain the Receiver’s authorization to initiate PPD
institution (the RDFI). The funds being deposited
entries through the ACH Network to the Receiver’s
can represent a variety of products, such as
account. For PPD debit entries, the authorization
payroll, dividend, interest, pension, and annuity
must
payments.
1. be in writing;
Direct Payment is a debit application, in which
companies use the ACH Network to electronically
2. be readily identifiable as an ACH authorization;
collect bill payments from their customers.
Through the use of a standing authorization, 3. have clear and readily understandable terms;
the consumer grants the company authority to
originate periodic debits to his account as bills 4. 
provide that the Receiver may revoke the
become due. Direct Payment is widely used with authorization only by notifying the Originator
recurring billing relationships, such as insurance, in the manner specified in the authorization;
mortgage, utility, and loan payments, as well as a and
variety of membership dues.
5. be either signed or similarly authenticated by
INITIATING A PPD ENTRY — the consumer. (Refer to the discussion below on
AN OVERVIEW the use of the similarly authenticated standard
• An Originator obtains authorization from the with PPD entries.)
Receiver to originate an entry to the Receiver’s
account. For PPD debit entries, the authorization The Originator must provide the Receiver a copy
must be in writing and signed or similarly of the authorization for all debit entries.
authenticated by the Receiver. For PPD credit
entries, the consumer’s authorization may be For credit entries to a consumer account, the
provided orally or by other non-written means. authorization may be obtained in writing, or it may
be obtained orally or by other non-written means.
• The Originator initiates PPD credits or PPD
debits to the consumer’s account, based on the Although an authorization is not required for
terms of the authorization. a reversing entry that complies with the Rules,
Originators are encouraged to obtain direct
authorizations for these entries.
OBLIGATIONS OF ORIGINATORS
Agreements with ODFIs An Originator must retain the original or a
An Originator must enter into a contractual reproducible copy of the Receiver’s authorization
agreement with the ODFI for the origination of for two years from the termination or revocation
ACH payments. In addition to being bound to of the authorization, and must be able to provide
the requirements of the NACHA Operating Rules, the ODFI with an accurate copy within the time
Originators should ensure that this agreement period required by the ODFI.
addresses any issues that may be specific to PPD
entries, as well as any specific obligations with

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG115
SECTION V – Standard Entry Class Codes
C H A P T E R 4 5   P R E A R R A N G E D PAY M E N T A N D D E P O S I T E N T R I E S

PPD Entries and the Similarly in these circumstances should pay particular
Authenticated Standard attention to compliance with the Federal Trade
As an alternative to providing a written signature Commission’s (FTC’s) Telemarketing Sales Rule
to authorize a PPD debit entry, the consumer (16 C.F.R. Part 310) and should take steps to
Receiver may similarly authenticate the written ensure that their authorization language is clear,
authorization that was previously delivered to conspicuous, and readily understood by the
him by the Originator. The similar authentication Receiver, and that their means of authentication
method must evidence both the consumer’s identity unambiguously indicates the Receiver’s assent
and his assent to the authorization. to the transaction.

For example, where there is an existing relationship, The Originator must retain a record of any
the Originator could have previously delivered the authentication code relayed by the consumer. If
written terms of the authorization to the consumer the consumer verbally expresses the authentication
with an explanation of a telephone payment code, the Originator must make and retain an audio
option. The consumer Receiver could authenticate recording of the consumer’s statement of the code.
his agreement to the terms of the authorization by If the consumer relays the authentication code by
key-entering into a VRU or speaking into a recorded key-entering it into a VRU, a record of the keystrokes
line a PIN provided with the authorization that must be retained. As with other ACH transactions,
identifies the consumer. (Either the consumer or proof of authorization is required. Originators must
the Originator could have initiated the telephone retain a copy of both the written authorization and
call in this case.) the consumer’s use of the authentication code.
Both must be accurately reproduced and provided
Alternatively, an Originator having no relationship to the ODFI upon request.
with the Receiver could deliver the terms of the
authorization to the Receiver in a catalog mailed Originators should be aware of the distinction
on an unsolicited basis. Either party (consumer or between PPD entries that are similarly authenticated
Originator) could initiate the telephone call, during using the telephone and Telephone-Initiated
which the consumer Receiver would authenticate Entries, which are discussed in Chapter 47 of these
his agreement to the terms of the authorization Guidelines.
by key-entering into a VRU or speaking into a
recorded line a PIN printed in the catalog. Source Documents for PPD Entries
While the NACHA Operating Rules do not define any
When a consumer uses the telephone to similarly specific requirements for obtaining the consumer’s
authenticate an authorization, Originators should routing and account number to generate a PPD
consider the following as best practices: entry, one common business practice used by
Originators is to use the MICR line from a check
• The PIN code should be a minimum of four to obtain this information. Originators must
digits. ensure that the correct Receiver’s account number
is contained in each ACH entry. Originators are
• If there is not an existing relationship between strongly encouraged to establish practices and
the Originator and the Receiver, the code procedures to ensure the validity and accuracy
should be printed on the written authorization of each Receiver’s account number for all entries
that is in the consumer’s possession when the transmitted into the ACH Network.
telephone conversion occurs. This demonstrates
the consumer’s possession of the authorization Originators may also look on the face of a check
language at the time of the call. for the routing information. Some financial
institutions may print the routing number and
• Outbound calls by an Originator to a consumer account number used for ACH purposes on the face
where there is no prior relationship pose of the item, if the information on the MICR line is
heightened risks for obtaining a properly not appropriate for ACH activity. In addition, some
authenticated,bona fide authorization.Originators financial institutions may provide their customers

OG116 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 5   P R E A R R A N G E D PAY M E N T A N D D E P O S I T E N T R I E S

with another source document that indicates the FORMATTING REQUIREMENTS

routing and account number to be used for ACH
Addenda Record – A PPD entry may be
entries.
accompanied by one addenda record (Addenda
Type “05”) carrying payment related ANSI ASC
In an effort to help ensure the proper routing and
X12 data segments (i.e., from the 103 Transaction
processing of ACH Entries, Originators should
Set, the 521 Transaction Set, 813 Transaction Set,
consider implementing practices and procedures
820 Transaction Set, 823 Transaction Set, or 835
that will enable them to verify the accuracy of
Transaction Set) to transport limited financial
routing numbers prior to the transmission of
information.
entries into the ACH Network.
For PPD entries with an addenda record, the
Notices of Variable Debits NACHA Operating Rules designate the “*” (asterisk)
Notice of Change in Amount as the data element separator (referred to as the
If the amount of a debit entry to be initiated to a “delimiter”) and the “\” (backslash) as the indicator
consumer account differs from the amount of the for the end of the segment (referred to as the
immediately preceding debit entry relating to the “terminator”).
same authorization, or differs from a preauthorized
amount, an Originator must send the Receiver Originators must be aware; however, that the
written notification of the amount of the entry NACHA Operating Rules do not require RDFIs to
and the date on or after which the entry will be provide Receivers with any remittance data that
debited. The Originator must provide this notice at accompanies a PPD entry.
least ten calendar days prior to the date on which
the entry is scheduled to be initiated. For more information on formatting payment
related ANSI ASC X12 data segments, refer to
Appendix Jin these Guidelines.
No Notice Required for Change Within
Agreed Range
The Originator is not required to give the notice RETURN OF PPD ENTRIES
above if (i) the Originator provides, and the PPD entries are governed by the same return
Receiver chooses, the option to receive such reasons and Return Reason Codes as other ACH
notice only if the amount of the entry falls outside debit entries (a complete listing of Return Reason
a specified range or if the entry differs from the Codes can be found within Appendix Four of the
most recent entry by more than an agreed upon NACHA Operating Rules).
amount, and (ii) the variation in the amount of
the entry is within the tolerance agreed to by the Most PPD returns will be made available to the
Receiver. Originator’s ODFI by the opening of business on
the second banking day following the Settlement
Notice of Change in Scheduled Debiting Date Date of the PPD entry.
An Originator that changes the scheduled date
on or after which debit entries are to be initiated However, when a Receiver has claimed that a PPD
to a Receiver’s account must send to the Receiver debit entry to his account was not authorized,
written notification of the new date on or after the Originator must be aware that its ODFI may
which entries are scheduled to be debited to the receive the return of the PPD entry for an extended
Receiver’s account. The Originator must send such period of time. In these cases, ODFIs, on behalf of
notification to the Receiver at least seven calendar their Originators, may receive PPD return entries
days before the first such entry is scheduled to as late as the opening of business on the banking
be debited to the Receiver’s account. Variation day following the 60th calendar day following the
in debiting dates due to Saturdays, Sundays, or Settlement Date.
holidays are not considered to be changes in the
For these extended returns, an RDFI is required to
scheduled dates.
have obtained a Written Statement of Unauthorized

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG117
SECTION V – Standard Entry Class Codes
CHAPTER 46  RE-PRESENTED CHECK ENTRIES

Debit from its Receiver. The Originator may request Reserve Regulation CC. However, RCK entries are
its ODFI obtain a copy of the Receiver’s written not subject to the Electronic Funds Transfer Act
statement regarding the unauthorized debit entry. (EFTA) or Regulation E.
Originators should work with their ODFIs to
establish procedures to request such information The legal framework for Re-presented Check Entries
from the RDFI when appropriate. is premised on the fact that the origin of each RCK
entry is based on a paper check that has been
Reinitiation of PPD Entries dishonored. Transfers of funds that were originated
PPD entries that have been returned for insufficient by a check, draft, or similar paper instrument are
or uncollected funds may be reinitiated up to two specifically excluded from coverage under the
times following the return of the original entry, EFTA (15 U.S.C. 1693a(6)) and Regulation E (12
provided such reinitiations are transmitted by the C.F.R. 205.3(c)(1)). Accordingly, if a Re-presented
Originator (or its ODFI on the Originator’s behalf) Check Entry is treated as a check transaction for
within 180 days of the Settlement Date of the purposes of the EFTA and Regulation E, it follows
original entry. that the UCC and Regulation CC should continue
to be the bodies of law that govern the rights and
For PPD entries returned for any other reason, the responsibilities of the parties involved with that
Originator must first remedy the reason for the payment, even though it has been converted to
return before reinitiating the transaction within electronic form.
the 180-day time period discussed above.
A Re-presented Check Entry is considered to be
a presentment notice for purposes of Revised
Article 4 of the Uniform Commercial Code (1990
Official Text). To that end, receipt of a Re-
CHAPTER 46
presented Check Entry constitutes presentment
Re-Presented Check Entries of the item in accordance with Article 4-110, and
return of the Re-presented Check Entry constitutes
(RCK) notice of dishonor or non-payment of the item in
accordance with Article 4-301. Provisions of the
Re-presented Check Entries (RCK) are Single- NACHA Operating Rules that are applicable to Re-
Entry debits initiated by Originators to re-present presented Check Entries are in accordance with
paper checks electronically after the paper checks Commentary provisions set forth in 12 C.F.R. Part
have been returned for insufficient or uncollected 229.37 of Federal Reserve Regulation CC.
funds.
ELIGIBILITY REQUIREMENTS FOR
The Rules governing RCK entries define specific ELECTRONIC RE‑PRESENTMENT
eligibility requirements and limits on the types An Originator may initiate an RCK entry only in
of checks that may be re-presented via the relation to an item that
ACH Network. In addition to the fundamental
requirement that only a check returned for • is an item within the meaning of Revised Article
insufficient or uncollected funds can be collected 4 of the Uniform Commercial Code (1990 Official
in this manner, Originators are also limited Text);
to converting only certain types of consumer
checks in amounts less than $2,500. More • is a negotiable demand draft drawn on or
detailed information on these and other eligibility payable through or at a participating DFI, other
requirements can be found later in this chapter. than a Federal Reserve Bank or Federal Home
Loan Bank;
LEGAL FRAMEWORK
• contains a pre-printed serial number;
In addition to applicable NACHA Operating Rules,
Re-presented Check Entries are also governed by
• is in an amount less than $2,500;
the Uniform Commercial Code (UCC) and Federal

OG118 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 46  RE-PRESENTED CHECK ENTRIES

• indicates on the face of the document that it was OBLIGATIONS OF ORIGINATORS

returned due to “Not Sufficient Funds,” “NSF,”
Agreements With ODFIs
“Uncollected Funds,” or comparable language;
An Originator using the ACH Network to collect
• is dated 180 days or less from the date on which checks that have been returned for insufficient or
the RCK entry is transmitted to the RDFI (that uncollected funds should consider modifications
is, the item to which the RCK entry relates is not to its agreement with its ODFI to address specific
stale-dated); issues related to the origination of RCK entries.
In addition to being bound to the requirements
• is drawn on a consumer account; and of the NACHA Operating Rules through its ODFI/
Originator agreement, an Originator and its ODFI
• has been previously presented should also address any processing obligations,
timing, liabilities, etc., that are unique to the
– no more than two times through the check RCK application. These modifications could, for
collection system (as a physical check, example, address the extent to which the Originator
substitute check, or image), if the RCK entry and ODFI would share liability for the following
is an initial entry, or warranties as they apply to the origination of RCK
transactions:
– no more than one time through the check
collection system and no more than one • the ODFI has good title to the returned item;
time as an RCK entry, if the RCK entry is a
reinitiated RCK entry. • all signatures on the item are authentic and
authorized;
Examples of items an Originator may not use to
initiate an RCK entry include the following: • the item has not been altered;

• non-cash items (as defined by Section 229.2(u) • the item is not subject to a defense or claim;
of Federal Reserve Regulation CC);
• the ODFI has no knowledge of any insolvency;
• drafts drawn on the Treasury of the United
States, a Federal Reserve Bank, or a Federal • the re-presented check entry accurately reflects
Home Loan Bank; the item;

• drafts drawn on a state or local government that • the underlying item — that is, the original check
are not payable through or at a Participating (or image or substitute check) — has not been
DFI; and will not be presented unless the RCK entry
has been returned by the RDFI;
• United States Postal Service money orders;
• the information encoded in magnetic ink on the
• items payable in a medium other than United item after issuance of the item is correct;
States currency;
• any restrictive endorsement placed on the item
• items payable to a person other than the is void or ineffective; and
Originator; and
• the ODFI will provide the RDFI with a copy of
• drafts that do not contain the original signature the front and back of the item to which the RCK
of the Receiver, including remotely created entry relates within ten banking days of the
checks, as defined by Regulation CC (e.g., the RDFI’s written request for a copy.
drawer does not sign a check but authorizes
another party to debit his account via a draft).

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG119
SECTION V – Standard Entry Class Codes
CHAPTER 46  RE-PRESENTED CHECK ENTRIES

Authorization/Notification Requirement (Note: Minor variations in how the payee’s name

Originators are required to provide notice to the appears in this field are acceptable; the name
Receiver, prior to the receipt of each check, that should, however, under all circumstances be
a check returned for insufficient or uncollected recognized by the check writer as the payee to
funds may be re-presented electronically via the whom he wrote the check);
ACH Network. The provision of this notice by the
Originator to the Receiver and the receipt of the • Company Entry Description – The description
consumer’s check together constitute authorization “REDEPCHECK” must appear within the
for the origination of an RCK entry. Company Entry Description Field of the
Company/Batch Header Record; and
The NACHA Operating Rules do not prescribe the
manner in which the Originator must provide the • Check Serial Number – The Check Serial Number
required notice to the check writer. However, the of the check to which the re-presented check
Originator must ensure that the notice clearly and entry relates must be placed within the Check
conspicuously states the terms of the Re-presented Serial Number Field of the RCK Entry Detail
Check Entry policy. It is recommended that notice Record.
provided at the point-of-sale be clearly displayed
on a sign at the point-of-sale, and that notice Collection of Return Fees
provided by a billing firm (i.e., utility company or An Originator may transmit an RCK entry for the
credit card company that issues a bill for payment) face amount of the returned check only. No fees
be clearly displayed on or with the monthly billing of any type may be added to the amount of the
statement. item when it is transmitted as an ACH entry.

Originators should be aware that, to protect An Originator desiring to use the ACH Network to
both the check writer and the RDFI, a check collect a Return Fee from a Receiver must originate
writer is permitted to sign a written statement a separate debit entry Return Fee Entry using the
of unauthorized debit and be recredited for the appropriate SEC Code and must follow all rules
amount of an RCK entry if the required notification governing the origination of Return Fee Entries.
by the Originator is not provided. In this situation, For specific information on Return Fee Entries,
an Originator should be aware that an RDFI has please refer to Chapter 54 in the Special Topics
an extended period of time within which to return Section of these Guidelines.
the entry. (Specifically, the RDFI must transmit the
return entry in such a time and manner that the Originators need to be aware that the requirements
return entry is made available to the ODFI no later of the NACHA Operating Rules regarding the
than the opening of business on the banking day origination of Return Fee Entries are in addition
following the sixtieth calendar day following the to any requirements defined by applicable state
Settlement Date of the RCK entry.) law governing the collection of Return Fees.
Originators are responsible for determining what
Restrictive Endorsements the applicable state laws are, if any, for each of
Any restrictive endorsement (e.g., “For Deposit their check-accepting locations that intend to, or
Only”) that is placed on the item by the Originator may, use the ACH Network for the collection of
or its agent is void or ineffective when the item is Return Fees.
presented as a re-presented check entry.
Some Originators may desire to place an
authorization stamp on the check being used
Formatting Requirements
for the payment of goods or services in order to
• Dollar Amount – RCK entries must be originated
collect a returned check fee in the event that the
for amounts less than $2,500.
check is returned for insufficient or uncollected
funds. In order for this practice to be compliant
• Company Name – The original payee on the face
with the NACHA Operating Rules, the following
of the check must appear within the Company
requirements must be met:
Name Field of the Company/Batch Header Record

OG120 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
CHAPTER 46  RE-PRESENTED CHECK ENTRIES

• An authorization placed on the check must be the front and back of the check to the ODFI for
signed (not initialed). This signature must stand its use, or for the use of the RDFI requesting the
alone, i.e., the authorization language for the information. If the check has been finally paid,
ACH debit entry must not be stamped in close the Originator must indicate this on the copy.
proximity to the maker’s signature on the check
such that it could appear that by signing the Return of Re-presented Check Entries
check, the checkwriter has also agreed to the Originators can expect to receive returned RCK
authorization. The signature for the authorization entries for a variety of reasons. Generally speaking,
must clearly relate to the authorization language RDFIs must return RCK entries to their ACH
itself. Operators by midnight of the second banking day
following the banking day of receipt of the RCK
• The authorization on the check must be readily entry. This return time period is applicable to the
identifiable as an ACH debit authorization and its return of most RCK entries, including RCK entries
terms must be clear and readily understandable returned by RDFIs that are located in states that (1)
(i.e., the print cannot be so small or smeared have not adopted Revised Article 4 of the Uniform
that a consumer would be unable to easily read Commercial Code (1990 Official Text) and have
the authorization and understand its terms). not revised its customer agreements to allow for
electronic presentment, or (2) require all canceled
• The authorization on the check must contain checks to a specific type of account to be returned
information that explains how the consumer to the Receiver within the periodic statement.
may revoke the authorization.
Originators should be aware, however, that an
• The Originator must provide the consumer with RDFI may also return an RCK entry so that it is
an electronic or hard copy of the authorization. made available to the ODFI by the opening of
business on the banking day following the sixtieth
• The Originator must retain the original or a calendar day following the Settlement Date of the
copy of the authorization for two years from the original entry in the following circumstances: (1)
termination or revocation of the authorization. the Receiver had placed a stop payment order on
the item to which the RCK entry relates, (2) the
Authorization language, if stamped on the back of
required notice stating the re-presented check
the check, should be in the endorsement space
entry policy was not provided by the Originator,
provided and not lower on the check. Before
(3) the check is ineligible, (4) all signatures on the
stamping the back of a check with anything other
check are not authentic or authorized, or the check
than an endorsement, Originators must ensure that
has been altered, (5) the amount of the entry was
they understand and are in compliance with both
not accurately obtained from the item, or (6) both
the NACHA Operating Rules and all regulations
the RCK entry and the item to which the RCK entry
that govern the collection of checks.
relates have been presented for payment. With the
exception of returns due to stop payment on the
Number of Presentments original item, the Receiver is required to provide
Originators may transmit a re-presented check the RDFI with a written statement of unauthorized
entry no more than twice after the first return of debit specifying the reason for the return.
a paper item, and no more than once after the
second return of a paper item. For additional information on written
statements of unauthorized debit, refer to
Retention of Copy of Item Chapter 26 in these Guidelines. A complete
The Originator must retain a copy of the front and listing of return reason codes, including those
back of the item (check) to which the RCK entry specifically addressing return conditions
relates for seven years from the Settlement Date unique to RCK, as discussed above, can be
of the RCK entry. When requested to do so by found within Appendix Four of the NACHA
the ODFI, the Originator must provide a copy of Operating Rules.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG121
SECTION V – Standard Entry Class Codes
C H A P T E R 4 7   T E L E P H O N E - I N I T I AT E D E N T R I E S

Stop Payments CHAPTER 47

Originators should be aware that RCK entries can
be returned for up to sixty days from settlement Telephone-Initiated Entries (TEL)
when a stop payment order is involved. As with
other Single-Entry ACH transactions, a Receiver
desiring to place a stop payment order on an RCK Telephone-Initiated Entries (TEL) are consumer
entry may do so, provided that he notifies his RDFI debit transactions. The NACHA Operating Rules
in such a time and manner that allows the RDFI a permit TEL entries when the Originator obtains
reasonable opportunity to act on the stop payment the Receiver’s authorization for the debit entry
order prior to acting on the debit entry. An RDFI orally via the telephone. An entry based upon a
returning an RCK entry on which a stop payment Receiver’s oral authorization must utilize the TEL
order is placed must use Return Reason Code R08 (Telephone-Initiated Entry) Standard Entry Class
and must transmit the return to its ACH Operator (SEC) Code.
by midnight of the second banking day following
the banking day of receipt of the RCK entry. INITIATING A TEL ENTRY —
AN OVERVIEW
However, because the Receiver’s original payment A TEL Entry is initiated by an Originator in response
was made by check, any instruction from the to a Receiver’s oral authorization that is spoken
Receiver to his financial institution to stop that over the telephone and includes the Receiver’s
payment will, in all likelihood, have been placed banking information. Based on the Receiver’s
on the RDFI’s check system instead of the ACH oral authorization, an ACH debit is initiated to the
system. When an RCK entry is re-presented Receiver’s account to collect payment for goods
electronically via the ACH Network, the RDFI or services. TEL Entries may be used for debit
should compare the entry against its check system transactions only. Originators may not utilize the
to determine whether any stop order on the item TEL SEC Code to transmit credit entries to the
exists. However, not all RDFIs have established Receiver’s account, unless those entries are credits
a link between their check and ACH systems to to reverse erroneous debits.
check for stop payment orders for these types of
transactions, potentially allowing an entry to be Existing Relationship
paid when it should not be. In these cases, the
A TEL Entry may be transmitted only in circumstances
NACHA Operating Rules also permit the RDFI to
in which:
return an RCK entry in such a time and manner
as to make the return available to the ODFI no 1. 
there is an existing relationship between the
later than the opening of business on the banking Originator and the Receiver, or
day following the 60th calendar day following the
settlement date of the original entry (as discussed 2. there is not an existing relationship between the
in the section above). This 60-day return time Originator and the Receiver, but the Receiver
frame provides a “safety net” for RDFIs that have initiated the telephone call to the Originator.
not built a bridge between their check and ACH
systems to check for stop payment orders. These The Originator and the Receiver are considered to
entries must be returned using Return Reason have an existing relationship when either:
Code R52 (Stop Payment on Item). A written
statement of unauthorized debit is not required for 1. there is a written agreement in place between
this return reason. the Originator and the Receiver for the provision
of goods or services (e.g., the Receiver has an
insurance policy with the Originator), or

2. the Receiver has purchased goods or services

from the Originator within the past two years.

OG122 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 7   T E L E P H O N E - I N I T I AT E D E N T R I E S

No Relationship reading it from a source document (e.g., the

A TEL Entry may not be used by an Originator Receiver’s check), which increases the potential for
when there is no existing relationship between the Receiver error in providing accurate information.
Originator and the Receiver, and the company has
initiated the telephone call. For purposes of the In some instances, the MICR information on
Rules, an Originator is not deemed to have such the Receiver’s check may not be appropriate for
an existing relationship with the Receiver with ACH processing resulting in increased exception
respect to TEL entries on the basis of a pre-existing processing. Originators can minimize the
relationship of one of its affiliates. potential for exception processing by employing
commercially reasonable procedures to verify that
Oral Authorization routing numbers are valid.
An oral authorization is that which is spoken by the
Verifying the validity of routing numbers can be
Receiver or is captured by an automated response
accomplished by:
system, again orally spoken.
• a component of a fraudulent transaction
• Voice Response Unit (VRU): A Voice Response
detection system,
Unit is also commonly referred to as Interactive
Voice Response Unit or IVR, which is interactive
• through a separate database or directory (either
technology that allows a computer to detect
commercial or proprietary), or
voice and keypad inputs.
• through other methods devised by the Originator,
RISK MANAGEMENT for example manual intervention such as calling
The NACHA Operating Rules require Originators to the Receiver’s financial institution.
implement a number of specific risk management
procedures relating to TEL entries: Although TEL provides a streamlined method
for Receivers to authorize ACH debit entries, this
Verification of Identity of Receiver process may be subject to misuse through the
Originators of TEL entries are required to utilize origination of unauthorized ACH debit transactions.
commercially reasonable procedures to verify the TEL entries are susceptible to origination that is the
identity of the Receiver (e.g. name, address, and result of deceptive and fraudulent telemarketing
telephone number). Originators need to establish practices by those Originators that use fraudulent
a commercially reasonable method (e.g., use of intent to:
a directory, database, etc.) to comply with this
• Debit the Receiver without obtaining the
requirement. The Originator is also advised to
Receiver’s authorization for such a transaction;
further verify the Receiver’s identity by verifying
pertinent information with the Receiver (e.g., past
• Cold call consumers with whom they have no
buying history, mother’s maiden name, Caller ID
existing relationship and subsequently debit the
information, shared secrets, account passwords,
Receiver; and
challenge responses, credit bureau information,
etc.)
• Use mail solicitations to instruct the consumer to
initiate the telephone call to the Originator and
Verification of Routing Numbers
subsequently attempt to sell goods or services
Originators of TEL entries are required to establish using deceptive marketing practices.
commercially reasonable procedures to verify that
routing numbers are valid. A TEL entry is a debit Commercially Reasonable
entry in which the Receiver is responsible for
For discussion on the concept of commercially
providing his routing number. In most instances,
reasonable standards, please refer to Chapter
the Receiver provides the routing number by
4 of these Guidelines.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG123
SECTION V – Standard Entry Class Codes
C H A P T E R 4 7   T E L E P H O N E - I N I T I AT E D E N T R I E S

OBLIGATIONS OF ORIGINATORS For both Single Entry and recurring TEL entries, the
Originator must clearly state during the telephone
Agreements with ODFIs
conversation that the consumer is authorizing an
Originators that wish to use the ACH Network to ACH debit entry to his account. The Originator
transmit TEL entries should consider modifications must understand that the Receiver must explicitly
to their agreements with their ODFIs to address express consent. Silence is not express consent.
the origination of this type of transaction. At
a minimum, additions to the ODFI/Originator Single Entry TEL Entries
agreement should include, but not be limited to:
Originators of Single Entry TEL entries are
obligated either to audio record the Receiver’s
• the Originator’s responsibilities and obligations
oral authorization or to provide, in advance of
with respect to the provision of specific
the Settlement Date of the entry, written notice to
information to the Receiver during the telephone
the Receiver that confirms the oral authorization.
call;
The authorization must be readily identifiable as
• the Originator’s requirement to audio record an authorization and must have clear and readily
the oral authorization or provide written understandable terms. The following minimum
confirmation of the Receiver’s authorization for information must be included as part of the
Single-Entry TEL entries; authorization:

• the Originator’s requirement to audio record the • the date on or after which the Receiver’s account
oral authorization and provide a written copy will be debited;
of the Receiver’s authorization for recurring TEL
• the amount of, or a reference to the method of
entries, to the extent required by Regulation E;
determining the amount of, the debit entry to
• verification of the identity of the Receiver; and the Receiver’s account;

• verification of routing numbers. • the Receiver’s name or identity7;

As the ODFI assumes additional warranties with • the account to be debited;

respect to the verification of the Receiver’s identity
• a telephone number that is available to the
and verification of the Receiver’s routing number,
Receiver and answered during normal business
the agreement should also address the allocation
hours for customer inquiries;
of liability between the Originator and ODFI for
any failure on the part of the Originator to comply
• the method by which the Receiver can revoke
with these and other requirements of the NACHA
the authorization;
Operating Rules.
• the date of the Receiver’s oral authorization;
Authorization Requirements and
Originators of TEL entries must obtain the Receiver’s
explicit oral authorization prior to initiating a debit • a statement by the Originator that the
entry to a consumer’s account. The authorization authorization obtained from the Receiver is for
must evidence the Receiver’s identity and assent to a Single-Entry ACH debit, a one-time electronic
the authorization. funds transfer, or other similar reference.

7
While Receivers are typically identified by name in an authorization,
the Rule includes the broader term “identity” to provide Originators
with the flexibility to use identity credentials such as user name and
password as part of the authorization. The Originator should have
other records that would then link those identity credentials to the
Receiver’s name.

OG124 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 7   T E L E P H O N E - I N I T I AT E D E N T R I E S

When the Originator of a Single Entry TEL entry provides additional guidance as to how ODFIs and
elects to provide the Receiver with written notice Originators can comply with e-Sign. Although
confirming the Receiver’s oral authorization, that NACHA cannot formally interpret Regulation E, the
notice must include, at a minimum, the pieces of guidance below provides additional information
information required to be included during the on how to comply with the Rules for authorization
telephone call, as described above. The Originator of recurring TEL entries. This guidance is not
should disclose to the Receiver the method by intended to be legal advice regarding compliance
which written notice will be provided if this option with Regulation E. ODFIs and Originators using
is used by the Originator. recurring TEL are responsible for determining
their own compliance with Regulation E and the
Recurring TEL Entries e-Sign Act.
Originators of recurring TEL entries are obligated
to both audio record the Receiver’s oral Authorization of Recurring TEL Entries under
authorization and to provide a written copy of Regulation E and e-Sign Act
the authorization to the Receiver, to the extent Under the Rules, an ODFI is responsible for the
required by Regulation E. The Originator should compliance of the telephone authorization process
disclose to the Receiver the method by which the with applicable law and for the validity of any
written copy will be provided. The authorization authorization obtained using such a process. To
must be readily identifiable as an authorization facilitate ACH participants’ understanding of
and must have clear and readily understandable such processes, the following provides high-level
terms. The following minimum information must outlines of two distinct situations that Originators
be included as part of the authorization: and ODFIs might face when considering whether
to permit consumers to authorize recurring ACH
• the amount of the recurring transactions, or debits from their accounts via the telephone. The
a reference to the method of determining the first scenario is based on the Rules as they existed
amount of recurring transactions; prior the effective date of the recurring TEL rule
(September 16, 2011), and results in “telephone-
• the timing (including the start date), number, initiated PPD transactions” in which a written
and/or frequency of the electronic funds authorization is electronically signed. This remains
transfers, or other similar reference, to the a permissible transaction format for institutions
consumer’s account; that follow the process outlined below. The second
scenario is based on the current rule for recurring
• the Receiver’s name or identity; TEL payments with an oral authorization. These
are merely two examples; there are many other
• the account to be debited; variations of the scenarios below that Originators
and ODFIs may wish to consider.
• a telephone number that is available to the
Receiver and answered during normal business Scenario 1 – Telephone-Initiated PPD Entries by
hours for customer inquiries; Electronically Signed Authorization

• the method by which the Receiver can revoke The consumer has received the clear and readily
the authorization; and understandable terms of the preauthorized
transfer in writing (either in a physical writing
• the date of the Receiver’s oral authorization. or in an electronic manner that satisfies the
e-Sign Act or other applicable law) prior to the
Authorizations for recurring TEL Entries need to telephone call. The writing includes spaces for
meet the writing and signature requirements of the consumer to record any variable information
Regulation E for preauthorized transfers, which (e.g., transaction amount, transaction frequency,
can be done by conforming to the e-Sign Act. account number and/or routing number). The
However, neither Regulation E nor its Commentary

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG125
SECTION V – Standard Entry Class Codes
C H A P T E R 4 7   T E L E P H O N E - I N I T I AT E D E N T R I E S

consumer then initiates a telephone call to the Other Considerations for TEL Entry
Originator, during which the consumer authorizes Authorizations
a recurring debit to his or her consumer account, Originators should understand that the term
and “signs” the written authorization either by “provide” is intended to mean that the Originator
inputting a code into the telephone keypad or by has utilized a medium (e.g., U.S. mail, fax, or other
providing the code orally to a customer service mail delivery method) to send the written notice
representative on a recorded line. This scenario to the Receiver. Any written notice or disclosure
could apply to an existing billing relationship, in required by the NACHA Operating Rules, including
which the billing company regularly sends bills in those for TEL entries, may be provided in electronic
writing (either paper or electronic) to an existing form (e.g., e-mail and SMS text message to a
customer. The bill would contain the clear and smartphone or mobile device). However, state and
readily understandable terms of the preauthorized federal laws may require Receiver consent before
transfers, and a code for the customer to input using electronic notices/disclosures.
during the telephone call.
The term “provide” does not imply receipt of such
Scenario 2 – Recurring TEL Entries by Oral notice by the Receiver. Originators that send a
Authorization copy of the written authorization or use a written
notice to confirm the authorization must afford
The consumer has not received the terms of the the Receiver the right to contact the Originator
preauthorized transfer in writing (either in a to correct any erroneous information contained
physical writing or in an electronic manner that within the notice using a provided telephone
satisfies the e-Sign Act or other applicable law) number. Compliance with the NACHA Operating
prior to the telephone call. The consumer initiates Rules does not eliminate the obligation to comply
a telephone call to the Originator, during which with other applicable laws.
the consumer authorizes a recurring debit to his
or her consumer account. The consumer provides An Originator using a voice response unit (VRU) to
his or her authorization, including his or her capture a Receiver’s authorization for a TEL entry
“signature” or “authentication” of the authorization, must understand that key-entry responses by the
via a recorded conversation. The consumer either Receiver to input data and to respond to questions
repeats or expressly confirms the authorization, does not qualify as an oral authorization. A VRU
including the account to be debited, the timing may be used by the Receiver to key enter data and
of the debits (e.g., monthly on the 1st business to respond to questions, provided that the actual
day of the month), and the amount (e.g., $500 per authorization by the Receiver is provided orally.
month), as well as other required elements of the
authorization. The Originator provides a written Retention of Record of Authorization for
copy of the authorization to the consumer (either TEL Entries
in a physical writing or in an electronic manner that For Single Entry TEL entries, the Originator must
satisfies e-Sign Act or other applicable law). This retain either the original, copy, or other accurate
scenario could apply to both: 1) an existing billing record of the Receiver’s oral authorization or a
relationship in which terms of the preauthorized copy of the written notice confirming the Receiver’s
transfer are not contained in writing on a bill; oral authorization for two years from the date of
and 2) a new billing relationship in which a new the authorization. For recurring TEL entries, an
customer wants to authorize recurring payments Originator must retain for two years from the
during the same telephone call that establishes termination or revocation of the authorization (i)
a new service (e.g., a new car insurance policy), the original, copy, or other accurate record of the
provided that the authorization is the result of an oral authorization, and (ii) evidence that a copy of
inbound customer call. the authorization was provided to the Receiver in
compliance with Regulation E. At the request of
the ODFI, the Originator must provide a copy of
the Receiver’s authorization.

OG126 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

Formatting Requirements 1. the anonymity of the Internet environment in

The Payment Type Code in the Entry Detail which parties are not certain with whom they
Record is used to indicate whether a TEL entry are doing business poses unique opportunities
is a recurring or a single entry payment. For a for fraud,
recurring TEL entry, this field must contain the
value “R”. For a single entry TEL entry, this field 2. the Internet as an open network requires special
must either contain the value “S” or be space-filled. security procedures to be deployed to prevent
unauthorized access to Receiver financial
The Individual Name Field of the Entry Detail information, and
Record of a TEL entry is a mandatory field.
Originators must ensure that the name of the 3. the sheer speed with which a large number of
Receiver is included within each TEL entry. Any payments can be transacted over the Internet
TEL entry where the Individual Name Field (volume and velocity).
contains all spaces or all zeros will be rejected and
returned by the ACH Operator. Technical solutions and business practices to
support WEB payments continue to evolve.
Note: The inclusion of all spaces or all zeros in any Therefore, the NACHA Operating Rules balance the
other mandatory filed will also cause the entry to need for security with the desire to maintain some
be returned by the ACH Operator. flexibility regarding the methods ACH Network
participants use to comply with the Rules. These
Operating Guidelines recommend methods ACH
participants can use to implement and comply
with the NACHA Operating Rules for WEB entries.
CHAPTER 48
(Note: In any case where these key components
Internet Initiated/Mobile Entries are not specifically required under the NACHA
Operating Rules, all are recommended by NACHA
(WEB) as sound business practices.)

Internet-Initiated/Mobile Entries (WEB entries) are INITIATING A WEB ENTRY —

used for the origination of debit entries (either AN OVERVIEW
recurring or single entry) to a consumer’s account
based on an authorization from the Receiver to the When to Use the SEC Code WEB:
Originator via the Internet or a Wireless Network, 1. 
WEB is appropriate to use when initiating
excluding oral authorization via these channels. In debit entries that have been authorized by the
addition, the WEB Standard Entry Class Code must Receiver via the Internet or a Wireless Network.
be used if the Receiver’s instructions for initiation
of the debit entry are communicated, other than 
Example: Authorization is obtained over the
orally, to the Originator via a Wireless Network, Internet accessed from a device that uses a
but the authorization has been given in some other wired or Wireless Network.
manner. This SEC Code helps to address unique
risk issues inherent to the Internet and Wireless 2. 
WEB is appropriate if the Receiver’s
payment environments through requirements for instructions for initiation of the debit entry are
added security procedures and obligations. communicated to the Originator via a Wireless
Network but the authorization has been given
BACKGROUND in some other manner.
Three unique characteristics of the Internet Example: An authorization was obtained from
warranted the development of the NACHA the Receiver in person but the Receiver sends a
Operating Rules for WEB: text message to communicate when to initiate
the debit entry.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG127
SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

When NOT to use the SEC Code WEB: when it is, or is not, appropriate to use the WEB
1. WEB is not appropriate if the authoriza­tion is SEC code.
oral.
When a consumer Receiver key enters information

Example: Authorization is given during a into a mobile device or computer as a means to
telephone conversation via a device over a communicate that information over the Internet
Wireless Network. to the Originator’s servers, the transaction should
be coded as a WEB Entry, even if the mobile
2. WEB is not appropriate if the Receiver’s device or computer is owned by the Originator.
instructions for initiation of the debit entry are An example of this scenario is when a consumer
communicated to the Originator over the Internet enters his or her account information on an
via a wired network but the authorization has insurance company’s web page, to authorize a
been given in some other manner. debit to pay for an insurance premium, even if the
consumer does so on an insurance agent’s laptop
Example: A written authorization was obtained or tablet computer. The WEB SEC code should
from the Receiver through the mail to debit be used in this scenario regardless of the physical
his account for a bill payment service but he location where the consumer and the agent meet
goes to the biller’s website to verify the amount (e.g., consumer’s home, agent’s office, local coffee
of the bill each month, this transaction would shop). The fact that the consumer and the agent
constitute a PPD entry rather than a WEB are meeting together does not result in the use of
entry. the POS SEC code, because the agent’s laptop is
being used as a means to communicate information
3. WEB is not appropriate to initiate credit entries over the Internet, not as a POS device.
except for a reversing entry to correct a previous
WEB debit entry. By contrast, a Point of Sale (POS) Entry is a debit
entry to a Consumer Account that is initiated by a
4. WEB is not appropriate to initiate debit or Receiver to pay for a purchase of goods or services
credit entries for business transactions. at an “electronic terminal” at the point of sale
or to receive cash back at such a location. This
5. WEB is not appropriate if the POS code would term is intended to be interpreted as defined in
otherwise apply, because the WEB format Regulation E, and the reference to “point of sale”
does not contain the necessary fields for means the Entry must be initiated by the Receiver
communication of POS transaction information. in-person at the Originator’s electronic terminal.
(Adjustments and other credit Entries related to
Example: A Receiver uses a third party near an original POS debit Entry are also coded as
field communication mobile payment service to “POS,” but may be initiated through back office
initiate a debit to his or her bank account to pay reconciliation processes.)
for goods at the point-of-sale. In accordance
with the Formal Rules Interpretation regarding Examples of electronic terminals for this purpose
the Proper Use of SEC Codes, the merchant are traditional terminals at stationary point-of-
(Originator) should use the POS SEC code sale locations such as grocery store cash registers
so that information regarding the merchant or automated gasoline pumps. The term also
identity and terminal location can be properly includes more innovative technology, such as
communicated to the RDFI. mobile devices owned or leased by a merchant
that are used as mobile check-out terminals, even
Other Considerations on When to Use WEB if the merchant uses the mobile device at a location
Rather Than Other SEC Codes for Scenarios that is not owned or rented by the merchant. For
Involving Mobile Devices example, a mobile tablet device that is used by
Mobile technologies are creating new mechanisms a farmer to accept payments at various farmers’
for initiating ACH entries. The following discussion markets around the state would be a point-of-
and scenarios provide additional guidance on

OG128 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

sale electronic terminal for this purpose, and ACH 3. transmits data via wireless technology
transactions initiated at such a device should be
coded as POS. • excluding a communication that begins and
ends with a wireline connection, but that is
It is also important to differentiate for this purpose routed by a telecommunications provider for
the proper use of the POS, MTE, POP and BOC a portion of the connection over a wireless
SEC codes. The following scenarios would not system.
result in the use of the WEB SEC code, even if any
part of the transaction utilizes a mobile device: COMMERCIALLY REASONABLE
For all WEB entries, each Originator is obligated
• If a transaction at a point-of-sale electronic
to ensure that certain aspects of a transaction have
terminal is initiated with an “access device” (as
been handled in a commercially reasonable manner.
that term is defined in Regulation E) or with
In addition, each ODFI warrants that the Originator
account and routing and transit information that
has handled those aspects of a transaction in a
is not machine-read from the MICR line, then
commercially reasonable manner. Those aspects of
POS is the correct SEC code to use.
the transaction include commercially reasonable
methods of authentication to verify the identity
• If the electronic terminal is an ATM (automated
of the Receiver, fraudulent transaction detection
cash dispensing machine), then MTE is the
systems, methodology to establish a secure Internet
appropriate SEC code to use.
session, and procedures to verify the validity of
• If the transaction is initiated by capturing the RDFI’s routing number.
information from the MICR line of a check
For a discussion on the concept of commercially
through a reading device at the point-of-purchase
reasonable standards, please refer to Chapter
and returning the check to the consumer, then
4 of these Guidelines.
POP is the correct SEC code to use.

• If the transaction is initiated by capturing SINGLE-ENTRY V. RECURRING

information from the MICR line of a check The WEB Standard Entry Class Code applies to
through a reading device at the point-of- both recurring and Single-Entry Internet/Mobile-
purchase itself or later for subsequent conversion initiated payments. In the case of WEB entries,
during back-office processing, and the check is a Single-Entry payment means a one-time transfer
not returned to the Receiver, then BOC is the of funds initiated by an Originator in accordance
correct SEC code to use. with the Receiver’s authorization for a single ACH
debit to the Receiver’s account.
UNSECURED ELECTRONIC NETWORK
For example: A Single-Entry WEB transaction
The Internet is an unsecured electronic network,
would be initiated if a consumer purchases a book
even though secure transmissions may be made
online.
over that otherwise unsecure network.
A recurring WEB entry is:
A network, public or private, is an unsecured
electronic network if:
1. an entry that has been set up to occur, based
on the Receiver’s authorization obtained via
1. 
it is not located entirely within a single,
the Internet or a Wireless Network, at regular
contiguous, physical facility, and
intervals without any additional intervention of
the Receiver.
2. transmits data via circuits that are not dedicated
to communication between two end-points for

Example: A monthly debit to the Receiver’s
the duration of the communication, or
account for a mortgage payment

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG129
SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

2. 
multiple entries, based on an authorization information (which includes, but is not limited to,
provided by the Receiver establishing a an entry, entry data, a routing number, an account
relationship with the Originator for a specific number, and a PIN or other identification symbol)
type of activity, that are originated each time via an Unsecured Electronic Network. ACH
upon the specific instructions of the Receiver. participants must abide by these requirements.

Example: An instruction via mobile device to a ACH data security is discussed in detail in
broker to purchase or sell securities. Chapter 4 of these Guidelines.

There are two primary reasons why a distinction OBLIGATIONS OF ORIGINATORS

has been made between recurring and Single-Entry
WEB transactions: Agreements with ODFIs
Originators choosing to utilize the ACH Network
1. 
Single-Entry payments have the potential to for initiating WEB transactions should consider
be more risky because the Originator and modifications to their agreements with their ODFIs
Receiver may not have a prior relationship to address the origination of these entries.
established, which makes robust authentication
more difficult and the possibility of fraud and These modifications should address:
exception processing higher.
• the extent to which the Originator and ODFI

Example, a one-time purchase of expensive will share liability for WEB transactions, and
electronic equipment is thought to be more
susceptible to fraud than a recurring payment • should define any specific processing obligations
for a telephone bill. relating to such transactions

While all of this is subjective and depends on Example: The NACHA Operating Rules require
each unique transaction, it is important for both an Originator of WEB entries to conduct or have
Originators and ODFIs to be able to recognize conducted on its behalf, annual audits to ensure
these payments in order to monitor them that the financial information it obtains from
separately for risk management purposes. Receivers is protected by security practices and
procedures.
2. 
To ensure that a Receiver has the ability to
place a stop payment order on a Single-Entry For more information on agreements, refer to
WEB transaction, the NACHA Operating Rules Chapter 5 in these Guidelines.
allow a Receiver to provide a stop payment
order to his financial institution as long as it Authorization Requirements
is given in such a time and manner that allows Originators of WEB entries must obtain the
the RDFI a reasonable opportunity to act on the Receiver’s authorization prior to initiating a
stop payment order prior to acting on the debit debit entry under this application. Although the
entry. For a recurring payment, the Receiver has NACHA Operating Rules do not prescribe specific
the right to place a stop payment only as long authorization language for the WEB application, the
as the request for the stop payment is made at authorization must conform to the requirements of
least three banking days prior to the scheduled the NACHA Operating Rules, which require that:
Settlement Date of the entry. The RDFI may, at
its discretion, honor such a stop payment order 1. the authorization must be in a writing that is
received within this three banking day period. signed or similarly authenticated by the Receiver
via the Internet or a Wireless Network, or
ACH DATA SECURITY REQUIREMENTS
2. 
the authorization is obtained in any manner
The NACHA Operating Rules impose specific data
permissible for other Standard Entry Class
security requirements for all ACH transactions that
Codes, but the Receiver’s instructions for the
involve the exchange or transmission of banking

OG130 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

initiation of the debit entry is communicated the strength of the association of an initial log-
via a Wireless Network (other than by an oral in with a later authorization. The burden of
communication), and demonstrating that the authentication process is
sufficiently linked to the authorization will be on
3. the authorization must be readily identifiable as the Originator and ODFI.
an ACH debit authorization;
For a discussion on the concept of similarly
4. the authorization must express its terms in a authenticated, please refer to Chapter 16
clear and readily understandable manner; and within these Guidelines.

5. 
the authorization must provide the Receiver One of the practical considerations for an Originator
with a method to revoke his authorization is how to present an authorization to a Receiver
by notifying the Originator in the manner over the Internet that both meets the requirements
prescribed. of the NACHA Operating Rules and is easily
understood. As long as the required information is
To meet the first requirement that the authorization included in the authorization language, Originators
be in writing, in the context of WEB entries, the have the flexibility to draft the language in any
Receiver must be able to read the authorization way that is user-friendly for their customers.
language displayed on a computer screen or other
visual display. The Originator should prompt the The following pieces of information should be
Receiver to print the authorization and retain a included in the authorization:
hard copy or electronic copy. The Originator must
be able to provide the Receiver with a hard copy 1. 
Express authorization language (“I authorize
of the authorization if requested to do so. Only the Company A” to debit my account)
Receiver may authorize the WEB transaction, and
not a Third-Party Service Provider on behalf of the 2. Amount of transaction:
Receiver.
• for a Single-Entry payment
The NACHA Operating Rules allow the use of a
digital signature or code to similarly authenticate • for a recurring entry that is for the same
a written authorization. Examples of methods amount each interval, or
used to similarly authenticate an authorization
include, but are not limited to, the use of digital • for a range of payments
signatures, codes, shared secrets, PINs, biometrics,
etc. To satisfy the requirements of the NACHA 3. The effective date of the transaction
Operating Rules, which parallel Regulation E, the
authentication method chosen must identify the 4. The Receiver’s account number
Receiver and demonstrate the Receiver’s assent to
the authorization. 5. 
The Receiver’s financial institution’s routing
number
Originators should understand the distinction
between authenticating a Receiver for general use 6. Revocation language
on a website (or marketing purposes, etc.) and
authentication in the context of an authorization. Originators must retain records of a Receiver’s
Authentication of an authorization is strongest authorization for two years after the termination
when the authorization and the authentication of or revocation of the authorization. In the physical
that authorization occur simultaneously or nearly world this record would be an original or copy
simultaneously. Although an initial website session of the signed authorization. In the electronic
log-in may constitute adequate authentication for world where the authorization will be similarly
a click-through authorization as part of the same authenticated, the Originator must keep a copy of
session, Originators and ODFIs should consider the authorization and a record of the authentication.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG131
SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

The Originator must also be able to provide these with existing customers, new customers or
records to the ODFI upon its request. The ODFI both. Originators with an established business
may request these records either for its own use relationship with the Receiver — whether
or to forward to the RDFI (the Receiver’s financial established online, in person, over the telephone,
institution). or some other method — can usually authenticate
those customers using shared secrets such as a
In the event that an Originator must demonstrate PIN, password or previous transaction history.
proof of a Receiver’s authorization to a WEB entry,
it should provide documentation that provides The Originator has the responsibility to choose an
transaction details including Receiver information appropriate solution for authentication that will
and sales documentation to show what goods and/ minimize the potential for fraudulent transactions.
or services were exchanged. Common examples in use today include asking
for several forms of identifying information and
Example: Originators can provide a screen checking that information against databases; asking
shot of the authorization language and then challenge questions based upon credit bureau or
the date/timestamp of the Receiver login and other information; or sending the Receiver a specific
the authorization process that evidenced both piece of information, either online or offline, and
the consumers’ identity and his assent to the then asking the Receiver to verify that information
authorization. as a second step in the authentication process.

RISK MANAGEMENT Originators should understand trends in the

adoption of multifactor authentication and layered
To help mitigate the added risk associated
security, or additional risk mitigation controls
with Internet/Mobile payments, Originators
to verify the identity of the Receiver in the
are obligated to comply with stringent risk
financial services industry. The Federal Financial
management requirements when originating WEB
Institution Examination Council (FFIEC) released
entries. At a minimum, Originators of such entries
guidance to financial institutions in October
must implement the following risk management
2005, Authentication in an Internet Banking
techniques:
Environment, which provides an appendix that
describes several of the authentication techniques,
Authentication
processes and methodologies that are widely
The best way Originators can minimize the available in the marketplace.8 Originators should
potential for fraudulent Internet/Mobile initiated periodically refer to the FFIEC for any updates to
ACH transactions is to employ robust authentication this guidance.
methods to verify the identity of the Receiver before
accepting ACH debit authorizations online. The Though user ID/PIN/password are still the most
more robust the authentication, the less likely the common solution for online authentication, there is
transaction will be fraudulent and the less likely growing interest in replacing passwords with more
the payment will be returned to the Originator as robust authentication such as use of additional
unauthorized. Since the Originator may ultimately authentication factors or securities layers.
be responsible for unauthorized or fraudulent ACH
transactions when those transactions are returned, For circumstances that demand heightened
it is to their benefit to incorporate adequate levels protection, institutions may consider multifactor
of authentication into their online ACH payment authentication. Multifactor authentication uses
processes. multiple characteristics to determine a Receiver’s
identity, for example by obtaining and verifying
When considering which authentication methods more than one of the following:
to use, Originators should determine whether
their WEB entry transactions will be conducted
8
The FFIEC Guidance, Authentication in an Internet Banking
­ nvironment, is available at hhtp://www.ffiec.gov/pdf/
E
authentication_guidance.pdf

OG132 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

• something the Receiver knows (password), • the type of goods or services being sold.

• something the Receiver has (a personal A fraudulent transaction detection system must be
computer), used no matter how small the transaction amount
or type. To not deploy any method or procedure
• something the Receiver is (voice or fingerprint), to detect transaction fraud is not considered
and commercially reasonable.

• someplace the Receiver is (geolocation). Annual Data Security Audits

Data loss or compromise not only hurts the Receiver,
Some other factors to consider in selecting an but can also damage a business’s reputation.
authentication method that is commercially Receiver trust is a key factor in building loyalty.
reasonable include typical transaction amount, It is in the Originator’s best interest to develop
type of goods offered, method of delivery, and and deploy practices that protect the integrity of
control of goods or funds. It is important to note Receiver information and the transaction, and to
that it will never be considered commercially ensure that these practices are audited for their
reasonable to have done nothing. Similarly, simply effectiveness.
assigning a password without validation of user
identity and allowing the Receiver to use that The NACHA Operating Rules for WEB transactions
password in the same Internet session as the sole require Originators to conduct an annual data
method of authenticating the Receiver is also not security audit to ensure that Receivers’ financial
commercially reasonable. information is protected by security practices
and procedures that ensure that the financial
Fraudulent Transaction Detection Systems information that the Originator obtains from
Using fraudulent transaction detection systems Receivers is protected by commercially reasonable
to screen WEB entries reduces the potential security practices that include adequate levels of:
for fraudulent ACH transactions. Fraudulent
transaction detection systems employ different 1. 
physical security to protect against theft,
methodologies and different features at varying tampering, or damage,
costs. The choice of which features should be
included in a fraudulent transaction detection 2. 
administrative, technical, and physical access
system for a particular Originator is generally a controls to protect against unauthorized access
decision to be made by the Originator. and use, and

Examples of fraudulent transaction detection 3. 

network security to ensure secure capture,
systems are systems that track payment history, transmission, storage, distribution and
behavior, purchase type, delivery information, etc. destruction of financial information.
Factors to consider when choosing a fraudulent
transaction detection system include, but are not While the NACHA Operating Rules only require
limited to: Originators to conduct an audit of their security
practices and procedures once a year, many
• the number of transactions processed by the companies are now opting to audit these practices
Originator, bi-annually or even quarterly due to the rapid
change of technology and security risks. It is
• the average dollar size of each transaction, therefore highly recommended that Originators of
WEB entries also conduct more frequent audits.
• the typical relationship with the Receiver
(existing or new), and

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG133
SECTION V – Standard Entry Class Codes
C H A P T E R 4 8   I N T E R N E T I N I T I AT E D / M O B I L E E N T R I E S

This audit requirement can be met in several ways. • Relevant employees must be educated on
It can be a component of a comprehensive internal information security and company practices
or external audit, or it can be an independent and their individual responsibilities.
audit that uses a commercially reasonable
generally accepted security compliance program. • Access controls should be in place to ensure
An Originator that is already conducting an audit adequate administrative, technical, and
of these practices and procedures for another physical controls:
area of its business is not required to have two
separate audits. However, the audit should address – Limit employee access to secure areas and
adequate levels of data security for the Originator’s to documents/files that contain Receiver
ACH operations. financial information.

The following sections detail the minimum – Ensure that terminated employees have no
components that need to be audited in order to be access to secure information and areas.
in compliance with the audit requirement. (Note:
In any case where these key components are not – Permit visitors only when absolutely
specifically required under the NACHA Operating necessary to these areas and information
Rules, all are recommended by NACHA as sound and ensure they are accompanied by an
business practices.) employee at all times.

1. Physical security to protect against theft, – Authenticate all access to any database
tampering or damage containing sensitive ACH information such
as financial information (e.g., passwords or
• Critical network, server, and passphrase, multifactor authentication such
telecommunications equipment should be as token devices, smart cards, biometrics,
placed in physically secure locations that or public keys).
permit access only to authorized personnel.
– Implement key-management procedures to
• Firewalls must be fully deployed with secured require split knowledge for dual control of
processes for administering those firewalls. keys (e.g., requiring two or three people
(or processes or procedures) to cooperate
• Firewalls must protect websites from in gaining authorized access to a system
inappropriate and unauthorized access. resource (data, files, devices) – a separation
of duties).
• Disaster recovery plans must be developed
and reviewed periodically. – Establish policies and procedures to monitor
and audit all user activity for personnel with
Personnel and access controls to protect against
2.  access to Receiver information in order to
unauthorized access and use detect exceptions.

• A formal set of security policies and Network security to ensure secure capture,
3. 
procedures must be developed that clearly transmission, storage, distribution, and
outline the corporate rules governing access destruction.
to sensitive financial data.
• Install and maintain a firewall configuration
• Hiring procedures should be developed to protect all Receiver financial information,
that will, at a minimum, verify application including but not limited to the company
information and check references on new network and databases, and portable
employees that will have access to Receiver electronic devices (e.g., employee laptops,
financial information. smartphones, etc.)

OG134 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

• Install and update anti-virus software on a Verification of Routing Numbers

regular basis. Many WEB entries are Single-Entry payments, and
Receivers frequently enter their routing numbers
• Ensure all system components have the latest manually using a keyboard. To minimize exception
vendor-supplied security patches installed. processing related to WEB entries, each Originator
is required to employ commercially reasonable
• Change vendor-supplied defaults before procedures to verify that routing numbers are valid.
installing a system on the network. Originators should try to ensure that the Receiver
enters the routing number correctly and that it is a
• Minimize retention and/or storage of all valid RDFI routing number for ACH transactions.
Receiver financial information.
Verifying the validity of routing numbers can be
• Develop a data retention and disposal policy accomplished by:
and schedule to include a process (manual
or automatic), to remove, at least on a • a component of a fraudulent transaction
quarterly basis, any unnecessary Receiver detection system,
financial information. Monitor these retention
schedules regularly. • through a separate database or directory (either
commercial or proprietary), or
• Receiver financial information should only
be stored permanently if it is required by law, • through other methods devised by the Originator,
regulation, rule, or a governing organization. for example manual intervention such as calling
the Receiver’s financial institution.
• Limit distribution of Receiver financial
and personal information and implement
procedures and policies to govern
the distribution of sensitive financial
information.

• Review data distribution policies and SECTION VI

Special Topics
procedures periodically.

• Encrypt Receiver data and financial

information at all points in the transaction
lifecycle from transmission to storage (e.g.,
128-bit RC4 encryption technology or
equivalent).
CHAPTER 50

• Regularly test security systems and processes Third-Party Service Providers

(e.g., vulnerability scans, external and internal
penetration testing, intrusion detection, file
integrity monitoring). A Third-Party Service Provider is an organization
other than an Originator, ODFI, or RDFI that
It is important to note that for transactions that performs a function of ACH processing on behalf of
involve some use of the Internet but are not the Originator, the ODFI or the RDFI. A function of
defined as WEB transactions, Originators are ACH processing could be the act of creating an ACH
encouraged to incorporate the security and risk file on behalf of an Originator or ODFI or acting as
management principles of the WEB rules, as a Sending Point or Receiving Point on behalf of an
applicable. For example, it would still be advisable ODFI or RDFI, respectively. A Third-Party Service
for the Originator to authenticate the Receiver Provider could also take on the role of a Third-
and conduct a data security audit to ensure the Party Sender, acting as an intermediary between
Receiver’s data is stored securely.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG135
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

the ODFI and the Originator with respect to the funds are ultimately owed. In some situations, the
initiation of ACH transactions. The organization Originator may enter into a contractual agreement
acting as a Third-Party Service Provider could be with a Third-Party Service Provider, such as a
a data processing service bureau, correspondent payroll processor or other type of service provider,
bank, payable through bank, or simply a financial to process the company’s payments. In these
institution acting on behalf of another financial cases, the Third-Party Service Provider, rather than
institution. the ultimate Originator of the payments, may have
the contractual relationship with the ODFI and the
Use of a Third-Party Service Provider can greatly account against which the funds are settled. While
enhance the origination and receiving capabilities this business model is commonplace in today’s
of the ODFI and RDFI. It is important that payments environment, it is important that ACH
both the ODFI and the RDFI are aware of their participants recognize that the Third-Party Service
responsibilities in ACH processing and ensure that Provider is not the Originator of the transactions.
those responsibilities are being met even if a third
party is performing the processing function. Using Third-Party Service Provider
a Third-Party Service Provider as a processing A Third-Party Service Provider is an entity other
agent does not relieve the financial institution of than an Originator, ODFI, or RDFI that performs
its obligations under the NACHA Operating Rules, any functions on behalf of the Originator, the
nor does it change the timing when actions must ODFI, or the RDFI with respect to the processing
be taken, e.g., use of a Third Party does not modify of ACH entries, including, but not limited to, the
the returns deadline. creation of ACH files.

ROLE OF THE THIRD-PARTY Sending Point

SERVICE PROVIDER A Third-Party Service Provider may act as a Sending
Third-Party Service Providers play increasingly Point, which is an entity that transmits entries to
larger and more complex roles in the processing an ACH Operator on behalf of an ODFI. A Sending
of ACH transactions. To understand the impact of Point may be an ODFI acting on its own behalf, or
rule provisions on Third-Party Service Providers, a Participating DFI, a commercial data processing
it is essential to have a clear understanding of the service organization, or a person operating a data
specific roles Third-Party Service Providers play in transmission facility that acts on behalf of one or
the ACH Network and the distinction between a more ODFIs. (NOTE: The NACHA Operating Rules
Third-Party Service Provider and an Originator. require an agreement between the ODFI and the
Sending Point when a Sending Point is used by the
Originator ODFI to transmit ACH entries to the ACH Operator
The definition of an Originator clearly distinguishes on its behalf.)
between an Originator of an ACH entry or file
and a Third-Party Service Provider to whom Receiving Point
some portion of the Originator’s ACH processing A Third-Party Service Provider may also act as a
requirements are outsourced. For purposes of the Receiving Points, which is an entity that receives
Rules, an Originator is defined as: entries from an ACH Operator on behalf of an
RDFI. A Receiving Point may be an RDFI acting on
A person that has authorized an ODFI its own behalf, a Participating DFI, a commercial
(directly or through a Third Party data processing service organization, or a person
Sender) to transmit, for the account of operating a data transmission facility that acts on
that person a credit entry, debit entry, behalf of one or more RDFIs.
or non-monetary entry to the Receiver’s
account at the RDFI. Third-Party Sender
A Third-Party Sender is an organization that is
The Originator is the party who has the contractual not an Originator that has authorized an ODFI
relationship with the Receiver and to or from whom or a Third Party Service Provider to transmit, for

OG136 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

its account or the account of another Third-Party to pay its employees, the Receivers. ABC Payroll
Sender a credit entry, debit entry, or non-monetary is a Third-Party Service Provider performing the
entry to the Receiver’s account at the RDFI. An function of creating the payroll file on behalf of
organization acting as Third-Party Sender is also a the Originator and transmitting it to the ODFI.
Third-Party Service Provider. ABC Payroll is also a Third-Party Sender because it
is acting as an intermediary between the employer
Third-Party Senders are a subset of Third-Party (the Originator) and MegaBank (the ODFI) and no
Service Providers. A Third-Party Sender is always contractual agreement exists between the ODFI
a Third-Party Service Provider that acts on behalf and the Originator.
of an Originator, but a Third-Party Service Provider
does not always act as a Third-Party Sender. A Example # 2
Third-Party Service Provider is considered to be a An employer contracts with ABC Payroll to handle
Third-Party Sender when it acts as an intermediary its payroll processing. ABC Payroll formats the
between the ODFI and the Originator and there is ACH file on behalf of the employer and forwards
no contractual agreement between the Originator it on to MegaBank, with which the employer has
and the ODFI. In this instance, the Third-Party a contractual agreement to originate ACH activity
Sender acts like the ODFI to the Originator. In any on its behalf. In this case, the employer holds
circumstance in which an Originator utilizes the an account with MegaBank that is credited or
services of a Third-Party Service Provider but has debited by MegaBank for settlement of the ACH
also executed a contractual agreement directly with transactions processed by ABC Payroll on the
the ODFI, the Third-Party Service Provider would employer’s behalf.
not be considered a Third-Party Sender and would
not be subject to the rule provisions governing The employer in this example is the Originator of
Third-Party Senders. The NACHA Operating Rules the payroll file because it is legally obligated to pay
require an agreement between the ODFI and its employees, the Receivers. ABC Payroll is a Third-
the Third Party Sender. Third-Party Senders and Party Service Provider performing the function of
their relationship with the ODFI are discussed in creating the payroll file on behalf of the Originator
Chapter 21 of these Guidelines. and transmitting it to the ODFI. In this scenario,
however, ABC Payroll is not a Third-Party Sender
The following examples help clarify the specific because a direct contractual agreement exists
circumstances in which a Third-Party Service between the ODFI and the Originator that binds
Provider is also considered to be a Third-Party the employer to the NACHA Operating Rules.
Sender.
Example # 3
Example # 1 An employer contracts with ABC Payroll to handle
An employer contracts with ABC Payroll to its payroll processing. ABC Payroll has further
handle its payroll processing. ABC Payroll has contracted with ACH Pay Service Provider for
a contractual agreement with its own financial the origination of its ACH processing into the
institution, MegaBank, to originate ACH activity on ACH Network. ACH Pay Service Provider has
its behalf, and ABC Payroll’s account at MegaBank a contractual agreement with its own financial
is credited or debited by MegaBank for settlement institution, MegaBank, to originate ACH activity on
of the ACH transactions processed by ABC Payroll. its behalf, and ACH Pay Service Provider’s account
In this example, there is no relationship between at MegaBank is credited or debited by MegaBank
the employer and MegaBank, and they do not for the settlement of transactions processed by
have a contractual agreement between them for ACH Pay Service Provider. In this example,
the origination of ACH payments. Instead, ABC there is no relationship between the employer
Payroll is an intermediary between the employer and MegaBank; they do not have a contractual
and MegaBank. agreement between them for the origination of
ACH payments. Similarly, there is no contractual
The employer in this example is the Originator agreement between ABC Payroll and MegaBank
of the payroll file because it is legally obligated

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG137
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

for the origination of ACH payments. In this case, (the employer) and the other Third-Party Sender
there are two intermediaries (ABC Payroll and (ACH Pay Service Provider), under which both
ACH Pay Service Provider) between the employer ABC Payroll and the employer agree to be bound
and MegaBank. to the Rules.

The employer in this example is the Originator ORIGINATION OF ACH ENTRIES

of the payroll file because it is legally obligated
The following figures provide several examples
to pay its employees, the Receivers. ABC Payroll
of how Third-Party Service Providers can be used
and ACH Pay Service Provider are both Third-Party
in the process of originating transactions into the
Service Providers acting as Third-Party Senders
ACH system.
because they are acting as intermediaries between
the employer (the Originator) and MegaBank
Example A
(the ODFI) and no contractual agreement exists
between the ODFI and the Originator. In this Figure 50-1 provides an example of how a Third-
case, ACH Pay Service Provider would have an Party Service Provider might be utilized to create
agreement with the ODFI (MegaBank) under which the ACH file for delivery to the ODFI prior to
ACH Pay Service Provider agrees to be bound to delivery to the ACH Operator.
the NACHA Operating Rules, and ABC Payroll
would have agreements with both the Originator

FIGURE 50-1

OG138 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

Example B
Figure 50-2 shows how a Third-Party Service
Provider could be utilized to initiate the ACH file
directly into the ACH Network on behalf of the
ODFI. The Third-Party Service Provider is acting
as the Sending Point on behalf of the ODFI.

FIGURE 50-2

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG139
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

Example C Originators and ODFIs, originating ACH entries on

Figures 50-3 and 50-4 provide illustrations of Third- behalf of the Originators.
Party Senders acting as intermediaries between

FIGURE 50-3

Third-Party Sender Environment #1

No agreement exists between the Originator and ODFI, but TPS assumes new obligations through agreement
with ODFI and through agreement with Originator.

OG140 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

FIGURE 50-4

Third-Party Sender Environment #2

No agreement in place between Originator and ODFI, but TPS assumes new obligations through agreement
with ODFI and through agreement with Originator and Third-Party Senders.

All participants in the origination process must control the dollar value or the type of transaction
clearly understand their roles and responsibilities to be originated. Since the ODFI is responsible for
in processing ACH files when a Third-Party Service the ACH entry, direct access to the ACH Network
Provider is used to perform an ACH processing (i.e., as a Sending Point) by a Third-Party Service
function. The ODFI must be aware that there may Provider should be analyzed very closely by the
not be controls in the ACH Operator software to ODFI.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG141
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

Agreements Example B
The NACHA Operating Rules require either (1) The ODFI must ensure that all agreements with
the execution of a contractual agreement between its ACH Operator(s) properly identify all Sending
the Originator and the ODFI under which the Points when the ODFI uses the facilities of a Third-
Originator agrees to be bound by the Rules and Party Service Provider as indicated in Example B.
acknowledges that it may not initiate entries in
violation of the laws of the United States, or (2) In addition to the agreements with the ACH
the execution of appropriate agreements (i.e., Operator(s), the ODFI must also ensure that proper
between ODFIs and Third-Party Senders, between agreements are in place between the ODFI and all
Third-Party Senders and Originators, and between Originators. Once a third party is established as
multiple Third-Party Senders themselves) under a Sending Point for an ODFI, it is possible that
which the Third-Party Senders agree to be bound entries could be initiated into the ACH Network
by the NACHA Operating Rules and Originators for a new Originator without the knowledge of the
agree to assume the responsibilities of Originators ODFI. The ODFI must establish procedures with
under the Rules and acknowledge that entries its Third-Party Service Provider to keep the ODFI
may not be initiated in violation of the laws of the informed of all ACH activity that is sent into the
United States. ACH system.

A matrix of issues to consider for the ODFI/ Third-Party Senders

Originator and ODFI/Third-Party Sender
agreements is provided in Appendix C of these Example C
Guidelines. In this example, no direct contractual agreement
exists between the Originator and the ODFI. As a
Third-Party Service Providers result, the ODFI is exposed to an increase in credit
risk because it has no direct claim against the
When agreements have been executed between the
Originator with respect to credit entries originated
Originator and the ODFI, it is also recommended
and for any debit entries returned by the RDFI, to
that agreements be entered into between the
the extent that the ODFI does not receive payment
Originator and the Third-Party Service Provider,
from the Third-Party Sender. The NACHA Operating
and between the Third-Party Service Provider and
Rules require that the ODFI and Third-Party Sender
the ODFI. The ODFI may decide to execute an
enter into an origination agreement that, among
agreement with the Third-Party Service Provider
other things, obligates the Third-Party Sender (i) to
depending on the facts and circumstances of
comply with the NACHA Operating Rules and (ii)
its business arrangement. In any case, these
to enter into an agreement with the Originator that
agreements should address responsibilities of each
includes at least the same provisions required by
party regarding quality of data, input schedules and
the origination agreement between the Originator
deadlines, and any other issues pertinent to the
and the ODFI. Such agreements help protect the
actual processing and delivery of the payment data.
ODFI against credit risk by providing it with the
ability to seek recovery of payment directly from
Example A
the Originator. These agreements should address
Some Third-Party Service Providers actively the responsibilities of each party with respect to
market ACH applications to Originators. The financial liability for each transaction, the quality
ODFI should ensure that its agreement with the of data, input schedules and deadlines, and any
Originator clearly provides that the Originator is other issues pertinent to the actual processing and
responsible for work transmitted by a Third-Party delivery of the payment data. The ODFI should
Service Provider acting on the Originator’s behalf. ensure that there is a process in place for the
Such a provision provides protection to the ODFI, Third-Party Sender to inform the ODFI of new
especially where no agreement exists between the Originators.
ODFI and Third-Party Service Provider.

OG142 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

Issues That Should Be Defined in ODFI and Electronic Records/Record Retention

Third-Party Service Provider Agreements The NACHA Operating Rules permit ACH
The agreement between the ODFI and Third-Party participants to retain ACH records electronically
Service Provider should: as an alternative to retaining such documents in
hard copy format. Specifically, the Rules allow any
• establish credit limits for batches and entire record, including any agreement, authorization, or
files. A batch or file that exceeds the credit Written Statement of Unauthorized Debit, required
limit should be brought to the ODFI’s attention to be in writing by the NACHA Operating Rules
before the file is deposited so the ODFI can to be created and retained in either hard copy or
either approve it as an exception or ask that it electronic form. The electronic record must (1)
be held until the next day; accurately reflect information contained within
the record, and (2) be capable of being accurately
• ensure senior management is aware of the reproduced for later reference, whether by
practice of utilizing a Third-Party Service transmission, printing, or otherwise. Electronic
Provider; records and record retention are addressed in
Chapter 4 of these Guidelines.
• require that the Third-Party Service Provider not
begin originating ACH entries for new companies Warranties and Indemnifications
under the ODFI’s routing number without prior Even if an ODFI utilizes a Third-Party Service
approval from the ODFI. The ODFI’s approval Provider in the origination process, the ODFI is
of each company should be contingent upon responsible for the entries that it originates into
the creditworthiness of the company; the ACH system. The ODFI warrants that it has
entered into an agreement with the Third-Party
• require that the Third-Party Service Provider
Service Provider when the third party is used
notify the ODFI of dollar totals for each file
to transmit ACH entries directly into the ACH
the processor deposits so that the ODFI can
Operator.
reconcile activity and settlement totals on
reports from the ACH Operator; and The ODFI also warrants that any Third-Party
Service Provider that performs a function of
• address who will be responsible for erroneous
ACH processing on behalf of the ODFI with
entries, who will handle rejects and in what time
regard to entries has conducted an annual audit
frame, who will handle returns and notifications
of compliance with the provisions of the NACHA
of change, how customer inquiries will be
Operating Rules. For more information on rules
handled, and what type of audit trail will be
compliance audit requirements as they apply to
provided.
a Third-Party Service Provider acting on behalf
of an ODFI, refer to the Rules Compliance Audit
For Third Party Senders, the agreement must
Requirements section within this chapter.
address any restrictions on the types of entries that
can be initiated, the termination of the agreement
The ODFI’s Routing Number appears in the
for Third Party Sender (or any Originator processed
Company/Batch Header Record and is repeated in
by the Third-Party Sender) breach of the Rules,
the first eight digits of the Trace Number in the
and the right of the ODFI to audit the Third Party
Entry Detail Record and Addenda Records. The
Sender for rules compliance.
financial institution that is represented by that
Routing Number is responsible for the warranties
The ODFI should also request information about
and indemnifications set forth in NACHA Operating
the processor’s financial condition, operating
Rules.
environment, what measures the processor has
taken to ensure that ACH files will be handled
The Sending Point can be the ODFI itself or an
accurately and on time, what type of physical
organization other than the ODFI. The Sending
security the processor has, how the data
Point is identified by the Routing Number in the
confidentiality is maintained, etc.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG143
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

Immediate Origin field in the File Header Record. ODFI does not receive payment from the Third-
Even if the Routing Number in the Immediate Origin Party Sender, the Originator of the entry agrees
field is that of a Third-Party Service Provider, it is to pay the ODFI.
the financial institution represented by the Routing
Number in the Originating DFI Identification Field • Performance of Originator Responsibilities –
that is considered the ODFI. The Third-Party Sender and its Originators are
responsible for the retention and delivery of
For all the reasons discussed above, it is critical any records, documentation and data related to
that ODFIs include use of a Third-Party Service copies of items, copies of source documents or
Provider for origination in their overall procedures records of authorization.
for analyzing risk and fraud.
Reversals/Erroneous Entries
Third-Party Sender Obligations It is critical that responsibility and accountability
Each Third-Party Sender is subject to a number of for errors are identified and understood prior to
additional obligations and liabilities with respect the origination of entries. The following issues
to the transmission of ACH entries. need to be resolved between the ODFI, Originator,
and third party:
• Identification of Originators – The Rules obligate
each Third-Party Sender to provide the ODFI • Who is responsible for detecting errors?
with any information that the ODFI considers
to be reasonably necessary to identify each • Who is responsible for correcting errors?
Originator for which the ODFI transmits entries.
Upon the receipt of a request from the ODFI for • In what time frame can errors be corrected?
such information, the Third-Party Sender must
provide the requested data to the ODFI within • Who will notify the Receiver of a reversing entry
two banking days. (e.g., the Originator, or ODFI/Third Party on
behalf of the Originator)?
• Warranties of/Indemnifications by Third-Party
Senders – Each Third-Party Sender that authorizes • Who is liable for any claim that may result from
an ODFI to transmit entries to a Receiver’s an error?
account warrants to the ODFI that the Originator
has agreed to assume the responsibilities of an Audit Trails
Originator, as required by the NACHA Operating ODFIs that use Third-Party Service Providers must
Rules. In any case in which the Originator fails establish procedures for tracing an entry into the
to perform its obligations as an Originator under ACH system. The organization that is the Sending
the Rules, the Third-Party Sender indemnifies Point is usually responsible for providing the
the ODFI against any loss. necessary data that demonstrates delivery to the
ACH Operator. In addition, some form of audit
• Performance of ODFI Obligations – If a Third- trail must be created in order to track the delivery
Party Sender performs any obligations of an of information from one party to the next until it
ODFI under the Rules, the Third-Party Sender reaches the Sending Point and, subsequently, the
must also perform the requirements of an ODFI ACH Operator.
under the Rules, and must warrant that it is
legally able to do so. The Rules do not relieve Returns/NOCs/Rejected Entries
the ODFI of any of its obligations when they are
Returns, notifications of change, rejected entries,
performed by a Third Party Sender.
and notice of rejected files or rejected batches
need to be handled expeditiously when they are
• Payment to ODFI – Each Third-Party Sender is
received by the ODFI. The ODFI is responsible for
obligated to make payment to the ODFI for all
determining, in its arrangements with Originators
credit entries and for all debit entries that are
and Third-Party Service Providers, who is
returned by the RDFI. In the event that the
responsible for handling these entries.

OG144 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

RECEIVING ACH ENTRIES Example B

Figures 50-5 and 50-6 show how Receiving Figure 50-6 provides an example of an RDFI that
Depository Financial Institutions (RDFIs) can utilizes the services of a third party to receive ACH
receive entries from the ACH Operator. files on its behalf. The RDFI’s Receiving Point is
the third party.
Example A
Figure 50-5 provides an example of an RDFI that
receives ACH files directly from the ACH Operator.
The RDFI acts as its own Receiving Point.

FIGURE 50-5

FIGURE 50-6

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG145
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 0   T H I R D - PA R T Y S E R V I C E P R O V I D E R S

The responsibilities of the RDFI in both examples that its Receiving Point is processing the ACH files
are outlined in the RDFIs chapters in Section III of in a manner that allows the RDFI to comply with
these Guidelines; however, the following provides the NACHA Operating Rules.
additional information on areas of importance that
should be addressed when a third party is used as Processing Functions
a Receiving Point, as in Example B. The Third-Party Service Provider as Receiving
Point can provide various levels of service to the
Agreements RDFI.
The RDFI needs to execute the appropriate
agreements with its ACH Operator in order to have Delivery Only
ACH files delivered to the proper Receiving Point. An RDFI may choose to use a third party simply
The RDFI should also enter into an agreement with to receive the ACH file. In this instance, the
the Third-Party Service Provider. This agreement Receiving Point usually is able to receive the file
should define the responsibility, accountability, more quickly or more efficiently than the RDFI.
and liability for the handling of ACH files. It All ACH Operators require electronic delivery to
should also address provisions for any additional Receiving Points. Using a third party with electronic
services the processor may offer to the RDFI, such delivery capability would enable the RDFI to meet
as processing returns, notifications of change, etc. the electronic delivery requirements of its ACH
Third-Party Service Providers should be aware that Operator. However, RDFIs that use third parties
the NACHA Operating Rules permit RDFIs to obtain as Receiving Points for the electronic delivery of
and retain ACH records electronically. For detailed ACH files must ensure that subsequent delivery
information on electronic records and electronic of the information to the RDFI is accomplished
record retention, refer to the Chapter 4 of these in such a manner as to ensure compliance with
Guidelines. the NACHA Operating Rules. For example, the
RDFI that uses a third party for electronic delivery
Warranties and Indemnifications and subsequently receives ACH information from
The RDFI is responsible for the entries made that third party via mail or courier will more than
available to it by the ACH Operator, even if the likely not be able to fulfill the requirements of an
RDFI utilizes a Third-Party Service Provider as a RDFI for funds availability and for meeting return
Receiving Point. The RDFI warrants that any Third- deadlines.
Party Service Provider that performs a function
of ACH processing on behalf of the RDFI with Delivery and Processing
regard to entries has conducted an annual audit An RDFI may choose to use a third party to receive
of compliance with the provisions of the NACHA and process its ACH activity. In this instance, the
Operating Rules and is otherwise in compliance third party usually posts the ACH entries to the
with the rules compliance audit requirements customers’ accounts for the RDFI and generates
governing the RDFI. reports to the RDFI indicating the functions it has
performed. The RDFI must receive these activity
The RDFI is identified by the Routing Number reports expeditiously in order to fulfill the various
in the Receiving DFI Identification Field of the responsibilities required of an RDFI for processing
Entry Detail Record of ACH files. The Receiving ACH entries, such as reviewing prenotifications,
Point is identified by the Routing Number in the initiating returns and notifications of change. The
Immediate Destination field of the File Header Third-Party Service Provider must ensure that all
Record. If these two numbers are different, the of the payment information is passed to the RDFI
organization represented by the number in the exactly as it was received from the ACH Operator.
Immediate Destination field is the Third-Party
Service Provider acting as a Receiving Point, and The processing function can also include data
the financial institution represented by the number retention, statement processing, fulfilling disclosure
in the Receiving DFI Identification field of the requirements, etc. The RDFI should also ensure
Entry Detail Record is the RDFI. Even if the RDFI that its processor is recognizing addenda records
is not the Receiving Point, the RDFI must ensure that accompany ACH entries and is processing

OG146 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 3   I N T E R P R E TAT I V E R U L E S

them according to regulatory requirements or the The annual audit under these rules compliance
specific requirements of the RDFI or the RDFI’s audit provisions must be completed by December
account holders. For additional information on 31 of each year.
processing addenda records for business Receivers,
see Chapter 39 of these Guidelines. The audit provisions contained in the Rules do not
prescribe a specific methodology to be used for
Additional Services the completion of an audit, but instead identify key
In addition to performing the processing functions rule provisions that should be examined during
for an RDFI to properly receive ACH entries, the audit process. ODFIs and their Third-Party
the third party may also handle returns and Service Providers, and RDFIs and their Third-Party
notifications of change for the RDFI. The RDFI Service Providers should rely on the guidance of
must ensure that the appropriate agreements have their auditors with respect to the specific auditing
been completed with the ACH Operator that will practices and procedures that must be followed.
enable the RDFI to use the Third-Party Service Please see Appendix Eight of the NACHA Operating
Provider for those functions. Rules for a complete list of audit requirements.

RULES COMPLIANCE AUDIT

REQUIREMENTS
CHAPTER 53
The NACHA Operating Rules require any Third-
Party Service Provider that performs a function of Interpretative Rules
ACH processing on behalf of an ODFI or RDFI to
conduct an annual audit of compliance with the
requirements of the NACHA Operating Rules. A This chapter is designed to provide ACH
function of ACH processing includes, but is not participants with an understanding of the process
limited to, the creation of ACH files or acting under which requests for formal interpretation
as a sending or receiving point on behalf of a of the NACHA Operating Rules will be accepted
Participating DFI. Third-Party Senders must review and processed. The objective of such Rules
their business models to determine which ODFI interpretations, as issued by the NACHA Board
obligations they perform and audit accordingly. of Directors, is to promote the purposes of or to
clarify the provisions of the NACHA Operating
Under the NACHA Operating Rules, ODFIs and Rules by providing appropriate guidance about
RDFIs warrant the completion of such an audit by whether a potential or particular use of the rule
their Third-Party Service Providers and Third-Party provisions is inconsistent with the Rules. Formal
Senders, as applicable. Financial institutions, Rules interpretations may also be issued for such
Third-Party Service Providers acting on their other purposes as the Board deems appropriate.
behalf, and Third-Party Senders must retain
documentation supporting the completion of an Unlike oral interpretations from NACHA and
audit of ACH rules compliance for a period of six information contained within the Guidelines,
years from the date of the audit and must provide which have generally been utilized to help provide
such documentation to the National Association amplification of the Rules but are not binding on
upon request. Participating DFIs, Third-Party ACH participants, official interpretations of the
Service Providers, and Third-Party Senders should NACHA Operating Rules that are issued under this
be aware that such documentation will not be process are as binding as the Rules themselves.
asked for in an arbitrary manner. Proof of an audit
will be requested only when deemed reasonably SUBMISSION REQUIREMENTS
necessary by the National Association. Acceptable
A request for a formal interpretation of the NACHA
documentation may include, but is not limited to,
Operating Rules (Rules) must be submitted to
a letter from an internal, outside or independent
the National Association by one of the following
auditor indicating satisfactory performance of all
ACH participants: (1) a NACHA Direct Financial
audits.
Institution member, (2) a Regional Payments

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG147
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 3   I N T E R P R E TAT I V E R U L E S

Association (either on its own behalf or on the Following an initial review of the issue, NACHA
behalf of its financial institution members), (3) an staff will forward the issue, along with a summary
ACH Operator, (4) a member of the NACHA Board of its preliminary evaluation of the issue, as
of Directors, or (5) NACHA staff. described above, to the Rules & Operations
Committee for action.
The request for interpretation must be submitted in
writing on the official letterhead of one of the ACH RULES & OPERATIONS COMMITTEE
participants defined above and must be signed by ACTION ON REQUEST FOR
an officer of the organization. INTERPRETATION
A written request for interpretation of the Rules Upon receipt of a written request for rules
must, at a minimum, include the following interpretation and appropriate documentation from
information: NACHA staff, the Rules & Operations Committee
will conduct an evaluation of the request and
• a detailed description of the issue or business determine which of the following criteria is
process to be evaluated; applicable:

• a complete analysis (i.e., legal, rules, etc.) of the The issue is a misinterpretation of existing rules
1. 
issue or business process, as applicable; and does not raise an issue of significance.

• identification of the specific rules affected; and 

In the event that the Rules & Operations
Committee (i) determines that the issue does
• any other relevant information. not have broad implications, (ii) determines
that the Committee does not have sufficient
Written requests should be directed to: information to make a decision on the issue,
or (iii) decides for other reasons not to issue
NACHA a written interpretation, the Committee will
Network Rules Department advise the submitter that no interpretation will
13450 Sunrise Valley Drive, Suite 100 be issued or that more information is needed.
Herndon, VA 20171 In such cases, NACHA will notify the submitter,
via telephone, of the Committee’s decision.
NATIONAL ASSOCIATION ACTION
2. The issue requires a rule amendment to address
ON REQUEST FOR INTERPRETATION
the concern.
Upon receipt of a written request for a Rules
interpretation, NACHA staff will review the 
The Rules & Operations Committee may
documentation provided to ensure that all determine that the issue under consideration
necessary documents have been included. A requires an amendment to the NACHA
preliminary review will also be conducted to Operating Rules. In such situations, the Rules &
evaluate whether the issue: Operations Committee will request that NACHA
staff advise the submitter that a rule change is
1. 
appears merely to be a misinterpretation of needed to address the concern and request the
existing rules and does not raise an issue of submission of a business idea into NACHA’s
significance; Business Idea Evaluation Process.

2. appears to require a rule amendment to address 3. The issue requires a formal interpretation of
the concern; or the Rules.

3. seems to require a formal interpretation of the 

In the event that the Rules & Operations
Rules to clarify the intent of the Rules. Committee determines that the issue under
consideration has broad implications network-

OG148 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
CHAPTER 54  RETURN FEE ENTRIES

wide, it will, with the assistance of NACHA staff, PERIODIC REVIEW OF WRITTEN
develop a recommended interpretation (with INTERPRETATIONS
appropriate legal review) and forward that
When amendments to the NACHA Operating Rules
written interpretation to the NACHA Board of
are implemented, it is possible that the change
Directors for its review, approval, and issuance.
may affect a section of the Rules about which a
All formal, written interpretations will include a
formal interpretation has been issued. In such
reference to the section(s) of the Rules to which
situations, the Rules & Operations Committee
the interpretation relates.
will review existing written interpretations to
determine whether such interpretations are still
NACHA BOARD OF DIRECTORS’ ACTION relevant and appropriate. If the Committee makes
ON PROPOSED INTERPRETATION a recommendation that these interpretations
The NACHA Board of Directors will review all should be removed, the Board of Directors would
proposed interpretations of the Rules recommended vote on such recommendation.
by the Rules & Operations Committee. If such
interpretations are approved by the Board, they
will be issued to the membership as discussed
later in this Chapter. In the event that a proposed CHAPTER 54
interpretation requires modification, the Rules
& Operations Committee will be requested to Return Fee Entries
develop a revised interpretation, which will be
re-presented to the Board for further review and
approval. A Return Fee is a fee charged by an Originator
(such as a merchant or biller) to a Receiver for a
debit Entry or other item (such as a check) that
CONFLICTS OF INTEREST
was returned for insufficient or uncollected funds.
Members of the Rules & Operations Committee or Many merchants and billers assess a Return Fee to
Board of Directors that represent an organization help recover costs associated with the collection
requesting the issuance of a formal rules of payments returned unpaid, including payments
interpretation will be precluded from participating returned because of insufficient or uncollected
in the development and approval process for that funds.
particular rules interpretation to avoid the potential
for any conflict of interest. Return Fees are often governed by state law. Most
states and the District of Columbia explicitly allow
ISSUANCE OF FORMAL RULES for the collection of a Return Fee when a check or
INTERPRETATIONS ACH debit is dishonored. Typically, the maximum
Once approved by the NACHA Board of Directors, amount of the return fee ranges from $20 to $50;
a formal, written interpretation of the NACHA it may also be calculated as a percentage of the
Operating Rules will be distributed to the NACHA face value of the check or ACH debit. Most states
family in the form of an Operations Bulletin. require notification to the check writer that a
These Operations Bulletins will also be accessible return fee will be assessed if the item is returned
via NACHA’s website. unpaid.

Formal rules interpretations will also be published COLLECTION OF RETURN FEES VIA
within the NACHA Operating Rules & Guidelines: THE ACH NETWORK
A Complete Guide to Rules Governing the ACH Originators may choose to collect Return Fees
Network and included as part of the ACH Rules via the ACH Network through the initiation of a
Online. Return Fee Entry. A Return Fee Entry is defined as
a Single-Entry debit to the Receiver’s account for

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG149
S E C T I O N V I – S p e c i a l To p i c s
CHAPTER 54  RETURN FEE ENTRIES

the purpose of collecting a Return Fee. ACH debit is authorized or the underlying check
is accepted. Notice meeting the requirements
An Originator may originate a Return Fee Entry, of Regulation E satisfies the authorization
to the extent permitted by applicable legal requirements for a Return Fee Entry regardless of
requirements, in relation to the return of: whether the account to be debited is a Consumer
Account or a non-Consumer Account.
(a) a debit Entry to a Consumer Account of a
Receiver; The notice must include the following, or
substantially similar, language:
(b) 
an ARC, BOC or POP Entry to a non-
Consumer Account of a Receiver; or “If your payment is returned unpaid,
you authorize us to make a one-time
(c) an item that was eligible to be converted electronic fund transfer from your
to a debit Entry, but was not converted to account to collect a fee of [$ ];”
an Entry.
or
An Originator may initiate a Return Fee Entry based
on the return of an ACH debit Entry identified “If your payment is returned unpaid,
above only if that Entry has been returned for you authorize us to make a one-time
insufficient or uncollected funds and contains electronic fund transfer from your
the return reason code R01 or R09. For a Return account to collect a fee. The fee will be
Fee Entry based on the return of a Check, the determined [by/as follows]: [ ].”
returned Check must be marked to indicate that it
was returned due to “Not Sufficient Funds, “ NSF,” A Return Fee Entry authorized by notice must be
“Uncollected Funds,” or comparable language. originated using the PPD Standard Entry Class
Code. More detailed information on formatting
OBLIGATIONS OF ORIGINATORS Return Fee Entries is provided later within this
chapter.
Agreements with ODFIs
An Originator must enter into a contractual The following are examples of how Originators
agreement with the ODFI for the origination of can obtain authorization for a Return Fee Entry
ACH payments, in which the Originator agrees via notice.
to be bound to the requirements of the NACHA
Operating Rules. Originators should work with – A merchant accepts a check eligible for
their ODFIs to determine what specific issues, if conversion from a customer but does not
any, should be included within that agreement convert the check to ACH (i.e., the merchant
with respect to the origination of Return Fee processes the payment as a check). The
Entries (e.g., formatting requirements, processing merchant can obtain authorization for a
obligations, timing, etc.). Return Fee Entry by posting notice at the
point-of-sale in conformance with Regulation
Authorization Requirements for Return E. If the check is returned for insufficient or
Fee Entries uncollected funds, the merchant can originate
Originators must obtain the Receiver’s authorization a Return Fee Entry.
prior to initiating a Return Fee Entry. This can be
accomplished in either of two ways. – A merchant accepts a check from a consumer
and converts it to a BOC Entry. Authorization
Authorization by Notice for the BOC Entry is obtained in conformance
Originators may obtain authorization for a Return with Regulation E and the Rules by posting
Fee Entry by providing the Receiver/check writer a conspicuous notice with clear and readily
with notice that conforms to the requirements understandable terms, and then obtaining the
of Regulation E at the time that the underlying customer’s signed check. The merchant can

OG150 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
CHAPTER 54  RETURN FEE ENTRIES

obtain authorization for a Return Fee Entry by 2. Telephone – the merchant directs
conforming to the Regulation E requirements the customer to call into a customer
in the same notice that served as authorization service center, where the customer
of the original BOC Entry. If the BOC Entry provides authorization for an ACH
is returned for insufficient or uncollected debit for the Return Fee (SEC Code
funds, the merchant can originate a Return “TEL”);
Fee Entry.
3. Web site – the merchant directs the
– A billing company obtains a written, signed customer to a corporate web site,
authorization to enroll a customer in monthly where the customer authorizes an
Direct Payment, which is collected via a ACH debit for the Return Fee (SEC
recurring PPD debit. The Originator can Code “WEB”).
obtain authorization for a Return Fee Entry
by providing notice in conformance with – A billing company obtains a written, signed
Regulation E in the authorization for recurring authorization to enroll a customer in monthly
debits. If any PPD debit is returned for Direct Payment, which is collected via a
insufficient or uncollected funds, the billing recurring PPD debit. One of the PPD debits is
company can originate a Return Fee Entry returned for insufficient or uncollected funds.
related to that specific PPD debit. The biller subsequently contacts the customer,
who agrees to pay a return fee. The customer
Authorization Other Than by Notice goes to the billing company’s web site and
Originators may also obtain authorization for authorizes an ACH debit for the return fee
a Return Fee Entry in any other form permitted (SEC Code “WEB”).
by the Rules with respect to any SEC Code for a
debit Entry to a Consumer Account (e.g., written Formatting Requirements
authorization for PPD or WEB, oral authorization Standard Entry Class Code
for TEL). A Return Fee Entry authorized in When notice is used as authorization, the
this manner must comply with the formatting Originator must format the Return Fee Entry as
requirements of the particular SEC Code used. a PPD (Prearranged Payment and Deposit) Entry.
More detailed information on formatting Return When the Return Fee Entry is authorized in a
Fee Entries is provided later within this chapter. manner other than by notice, the Originator must
format the Return Fee Entry using the Standard
Below are examples of how an Originator can Entry Class Code that corresponds to the manner
obtain authorization for a Return Fee Entry in a in which authorization was obtained (i.e., PPD
manner other than by notice. for written authorization, WEB for written
authorization via the Internet or mobile device,
– A merchant accepts a check from a customer TEL for oral authorization).
and does not convert the check to ACH (i.e.,
processes as a check). The check is returned Company Entry Description
for insufficient or uncollected funds. The
Originators must populate the Company/Entry
merchant subsequently contacts the customer,
Description field of each Return Fee Entry with
who agrees to pay a Return Fee. The merchant’s
the words “RETURN FEE” (all capitals) to enable
options for obtaining authorization include:
Receivers to identify Return Fee Entries to their
accounts. This descriptive statement applies to all
1. In-person – the merchant directs
Return Fee Entries, regardless of the manner in
the customer to return to the store
which authorization was obtained, the nature of
or location, and obtains written
the underlying transaction, or the SEC Code used
authorization for an ACH debit for
in the Entry.
the Return Fee (SEC Code “PPD”);

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG151
S E C T I O N V I – S p e c i a l To p i c s
CHAPTER 54  RETURN FEE ENTRIES

Company Name Return Fees on Return Fees

The Originator of a Return Fee Entry must identify An Originator is prohibited from initiating a Return
itself in the Company Name field using the identical Fee Entry in relation to an underlying ACH debit
name that was used in the underlying ACH debit that is itself a Return Fee Entry (that is, no return
to which the Return Fee relates. If the underlying fee on a return fee).
transaction for the Return Fee is a check, the
Originator must identify itself with the name by Return of Return Fee Entries
which it is known to and readily recognized by Return Fee Entries are governed by the same return
the Receiver. This information is also provided to reasons and Return Reason Codes as other ACH
consumers on their periodic statements. debit entries. A complete listing of Return Reason
Codes can be found within Appendix Four of the
Individual Identification Number NACHA Operating Rules.
When a Return Fee Entry relates to an underlying
ACH debit that carries a check serial number (ARC, Most Return Fee Entry returns will be made
BOC, POP and RCK), or relates to an underlying available to the Originator’s ODFI by the opening of
check transaction, the Originator must include the business on the second banking day following the
check serial number of the underlying transaction Settlement Date of the Return Fee Entry. However,
in the Individual Identification Number field of when a Receiver has claimed that a Return Fee
the Return Fee Entry. Although some financial Entry to his account was not authorized, the
institutions provide this information to consumers Originator must be aware that its ODFI may receive
on their periodic statements, the NACHA Operating the return of the Return Fee Entry for an extended
Rules do not require them to do so. However, period of time. In these cases, ODFIs, on behalf of
the information in this field is available to RDFIs their Originators, may receive Return Fee Entries
for purposes of customer service research, as late as the opening of business on the banking
enabling them to assist their customers in further day following the 60th calendar day following the
recognizing the Return Fee Entry and relate it to a Settlement Date of the entry. For these extended
specific underlying transaction. returns, an RDFI is required to have obtained a
Written Statement of Unauthorized Debit from
Limitations on the Origination of Return its Receiver. The Originator may request a copy
Fees and Return Fee Entries of the Receiver’s written statement regarding the
Number of Return Fee Entries Permitted unauthorized entry. Originators should work with
their ODFIs to establish procedures to request such
An Originator may impose only one Return Fee in
information from the RDFI when appropriate.
relation to an underlying transaction that has been
returned because of insufficient or uncollected
Re-initiation of Return Fee Entries
funds, regardless of whether the fee is collected
via the ACH Network or otherwise, and regardless A Return Fee Entry that is itself returned because
of the number of times the underlying transaction of insufficient or uncollected funds may be re-
is returned. For example, a single underlying ACH initiated up to two times following the return of
debit can be returned for insufficient funds as many the original Return Fee Entry, provided that such
as three times, but the Originator is permitted to re-initiations are transmitted by the Originator (or
collect only one Return Fee for that entry. its ODFI on the Originator’s behalf) within 180
days of the Settlement Date of the original Return
Timing of Return Fee Origination Fee Entry.
A Return Fee Entry that is authorized by notice
must have a Settlement Date that is no later than 45
days after the Settlement Date of the ACH Return
Entry or the receipt of the return of the underlying
check transaction.

OG152 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

CHAPTER 55
PATIENT PROTECTION AND
AFFORDABLE CARE ACT
Healthcare EFT Regulations and On March 23, 2010, the Patient Protection and
the ACH Network Affordable Care Act (ACA) became law. Section
1104, Administrative Simplification, of the
Affordable Care Act requires the Department of
This chapter provides information on recent Health and Human Services (HHS) to adopt a
Federal healthcare regulations, the adoption standard for healthcare EFT transactions, as well
of a healthcare electronic funds transfer (EFT) as industry-vetted operating rules regarding the
standard, and the adoption of healthcare industry use of the transactions. On January 10, 2012,
operating rules for EFT and electronic remittance HHS issued an Interim Final Rule with Comment
advices (ERA). The chapter also describes the (“January IFC”) on Administrative Simplification:
impacts of this healthcare legislation on financial Adoption of Standards for Health Care Electronic
institutions and outlines efforts undertaken by Funds Transfers (EFTs) and Remittance Advice.9
NACHA in support of the healthcare industry. For The January IFC: 1) adopted the NACHA Corporate
detailed information on the Healthcare EFT & Credit or Debit with Addenda Record (CCD+) as the
ERA Operating Rules, please refer to the Council standard for healthcare EFT; 2) adopted the ASC
on Affordable Quality Healthcare (CAQH)’s X12 835 TRN Segment (“reassociation number”) as
Committee on Operating Rules for Information the standard for the data content of the Addenda
Exchange (CORE) at http://www.caqh.org/CORE_ Record of the CCD; and 3) discussed NACHA’s
phase3.php role in the development and maintenance of the
CCD+ through the NACHA Operating Rules.10
BACKGROUND – LEGISLATION AND The IFC became a final rule on July 10, 2012 and
HEALTHCARE INDUSTRY RULES clarified that if a healthcare provider requests that
Since 1996, three major pieces of healthcare a health plan use the standard EFT transaction (the
legislation have been passed that address CCD+), the health plan is required to do so. The
administrative simplification within the healthcare compliance date for all covered entities is January
industry via the adoption of standard transactions 1, 2014.
between health plans and healthcare providers.
These laws are the: The Healthcare EFT Standard
In the January IFC, HHS divided the ACH
• Health Insurance Portability and Accountability transaction flow into three chronological stages,
Act of 1996 (HIPAA) each of which includes a separate electronic
transmission of information:
• American Recovery and Reinvestment Act
(ARRA) – 2009, which contained the Health • Stage 1 – Payment Initiation – a health plan’s
Information Technology for Economic and order, instruction, or authorization to its financial
Clinical Health Act (HITECH) institution to make a healthcare claim payment
using an electronic funds transfer (EFT) through
• Patient Protection and Affordable Care Act the ACH Network.
(ACA) of 2010
• Stage 2 – Transfer of Funds – the transfer and
This chapter focuses on the new regulations and settlement of funds from one account to another
mandates included in the ACA and their impact on account.
the financial services industry.

9
http://www.gpo.gov/fdsys/pkg/FR-2012-01-10/pdf/2012-132.pdf
10
HHS finalized the rule on July 10, 2012 with no changes.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG153
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

• Stage 3 – Deposit Notification – transmission

of information from the Receiving Depository
Financial Institution (RDFI) to the Receiver
that the payment has been deposited to the
Receiver’s account.

The January IFC adopted NACHA’s Corporate

Credit or Debit Entry (CCD Entry) with Addenda
Record, as defined within Appendix Three of the
2011 NACHA Operating Rules11, as the healthcare
EFT standard for Stage 1 (Payment Initiation).12

The January IFC also adopted the X12 835 TR3

TRN Segment as the standard for the data content
for the addenda record of the CCD Entry and
requires health plans to populate the CCD Entry’s
addenda record with this data segment. Section 2.4
(Segment Detail, TRN Reassociation Trace Number)
of the January IFC includes specifications for the
addenda content. The TRN Segment includes,
consecutively, the Trace Type Code (TRN01), the
Reference Identification (TRN02), the Originating
Company Identifier (TRN03), and if appropriate,
the Reference Identification (TRN04).

The January IFC did not adopt standards for Stages

2 (Transfer of Funds) and 3 (Deposit Notification)
of the healthcare EFT.

Figure 55-1 on the following page illustrates

the three stages of the ACH transaction flow as
identified by HHS.

11
From CMS FAQs, “While the implementation specifications in the
2011 NACHA Operating Rules & Guidelines are the adopted standard
for the CCD+Addenda, any version of the NACHA Operating Rules &
Guidelines can be used as long as the implementation specifications for
the CCD+Addenda do not differ from those in the 2011 version.”
12
Note: HHS adopted only the chapter and appendices of the NACHA
Operating Rules that include implementation specifications for the
CCD+Addenda rather than all rules governing CCD entries.

OG154 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

Health Plan Stage 1 Stage 2 Stage 3 Provider

(Originator) Payment Transfer of Deposit (Receiver)
Initiation Funds Notification

Health Provider’s
Plan’s FI FI
Treasury Treasury
(ODFI) (RDFI)

Health care payment/processing information

via EFT
Claim Billing and
Processing Collection
ERA

FIGURE 55-1  STAGES OF HEALTHCARE EFT

Adoption of Healthcare Operating Rules • Phase III CORE EFT & ERA Reassociation
On August 20, 2012, HHS issued another IFC (CCD+/835) Rule; and
(“August IFC”) on Administrative Simplification:
Adoption of Operating Rules for Health Care • Phase III CORE Health Care Claim Payment/
Electronic Funds Transfers (EFT) and Remittance Advice Infrastructure Rule
Advice Transactions13. The August IFC adopted
the CAQH CORE Phase III CORE EFT & ERA Of the five CORE Operating Rules adopted, the
Operating Rule Set as the industry-vetted operating EFT & ERA Reassociation Rule will have the most
rules for EFT and ERA. The CORE rule set includes direct impact on financial institutions for the
the following: reasons below.

• Phase III CORE EFT Enrollment Data Rule; • It requires health plans to proactively inform
healthcare providers during EFT enrollment that
• Phase III CORE ERA Enrollment Data Rule; the healthcare provider will need to contact its
financial institution to arrange for the delivery
• Phase III CORE Uniform Use of CARCs and of the CORE-required Minimum CCD+ Data
RARCs14 Rule, including CORE-required Code Elements. It also states that the “healthcare
Combinations for CORE-defined Business
Scenarios;

http://www.gpo.gov/fdsys/pkg/FR-2012-08-10/pdf/2012-19557.pdf
13

CARCs – Claims Adjustment Reason Codes; RARCs – Remittance

14

Advice Remark Codes

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG155
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

provider must proactively contact its financial (PHI) they receive and process on behalf of their
institution to arrange for the delivery of the customers. The healthcare EFT standard does not
CORE-required Minimum CCD+ Data Elements.” carry PHI in the addenda record. It is mandated to
carry only the TRN Reassociation Trace Number,
• It identifies the Core-required Minimum CCD+ which does not contain PHI. As a result, RDFIs
Data Elements as three fields in the ACH CCD that only receive and process the CCD+Addenda
record that are used for reassociation of the for their healthcare customers are not subject to
ACH Entry and the Electronic Remittance Advice HIPAA Privacy and Security regulations.
(ERA): 1) the Effective Entry Date field (CCD
Record 5, Field 9); 2) the Amount field (CCD The Medicare EFT mandate, the identification of
Record 6, Field 6); and 3) the Payment Related the CCD+ as the healthcare EFT standard, and the
Information field (CCD Record 7, Field 3). development and implementation of the EFT &
ERA Reassociation Trace Number operating rules
Due to the CORE EFT & ERA Reassociation will impact all financial institutions that service
Rule, financial institutions that have healthcare healthcare providers and health plans.
providers as customers can expect an increase
in requests to receive this information for To meet the ACA goals for Administrative
reassociation. The August IFC estimates that there Simplification, more health plans will require EFT
are 708,842 healthcare providers in the U.S. It claims reimbursement payments for healthcare
further estimates that the current usage of EFT providers that accept their medical insurance
by the healthcare industry of 33 percent for all coverage, and a larger portion of the 2.5 billion
healthcare claim payments will rise to 84 percent health claims paid16 annually will move to EFT.
by 2023.15 The combination of the percentage For financial institutions, this shift has the potential
increase across a large number of entities would to impact not only the ACH department — with
result in a significantly larger number of healthcare additional volumes and mandatory delivery of the
EFT payments received by RDFIs, for which remittance information — but also the lockbox
reassociation information will be contained within and check processing departments as volumes
the ACH record. move from check to ACH, as well as the cash
management or treasury management areas as
Medicare Mandate healthcare providers and health plans request
The final rule also mandates the use of EFT additional services.
for the reimbursement of all Medicare claims
reimbursement, effective January 1, 2014. This should be viewed as an opportunity for
financial institutions to improve and strengthen
their relationships with their healthcare customers
International Healthcare Payments
through education and product or service outreach
The Final Rule recognizes that the healthcare EFT rather than a regulatory requirement. Healthcare
standard CCD+ Addenda record cannot be used for providers are sometimes unaware of products and
payments made to or from countries outside the services that financial institutions can provide to
United States and that all international transactions help them automate and improve their back-office
must utilize the NACHA IAT format. processing. Repackaging existing products (e.g.,
equipment and facilities loans, Direct Payment via
IMPACT OF HEALTHCARE LEGISLATION ACH for the collection of patient outstanding debt,
ON FINANCIAL INSTITUTIONS ACH Debit Blocks and Filters, etc.) that focus on
The impact of healthcare legislation on financial proactive outreach and education to healthcare
institutions varies, depending on the products and customers can strengthen customer relationships
services they provide to the healthcare industry and demonstrate financial institutions’ willingness
and what, if any, Protected Health Information to help their healthcare customers meet new
healthcare legislation requirements.

 ttp://www.gpo.gov/fdsys/pkg/FR-2012-08-10/pdf/2012-19557.pdf
h
15 16
 cKinsey Quarterly. Overhauling the US health care payment system,
M
Table 6, EFT and ERA Usage between 2013 and 2023 June 2007, page 8.

OG156 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

Delivery of Payment Related Information For financial institutions, this means that any
Healthcare customers’ increased demand for the healthcare provider customers not currently
delivery of the data contained in the Payment receiving the payment related information from the
Related Information Field of the CCD+ Addenda CCD+ transactions will be requesting the CORE-
Record will impact all financial institutions. The required Minimum CCD+ Reassociation Data
payment related information for the healthcare Elements from customer-facing staff (e.g., branch
CCD+ will contain the TRN Reassociation Trace staff, customer service staff, cash management
Number created by the health plan. This number staff, etc.). Financial institutions will need to
allows the healthcare provider to tie the CCD+ recognize requests for CORE-required Minimum
payment to the correct ERA, which is currently CCD+ Reassociation Data Elements and either
received through another channel. The ERA direct healthcare providers to appropriate staff to
contains information on the paid claim, along with setup the information delivery service, or setup
any adjustments to the claims adjudication process. the service for them.

Readers should note that, among ACH participants, The delivery of the contents of the Payment Related
the Payment Related Information is commonly Information Field is required by the NACHA
referred to as the “remittance information.” For a Operating Rules once requested by the Receiver;
CCD that is a Health Care EFT, the Payment Related after such a request it is not an optional service.
Information will always contain the “reassociation All financial institutions must be able to deliver
number” (i.e., the ASC X12 835 TRN Segment), and the information contained in the Payment Payment
not detailed remittance information that contains Related Information field of the CCD+ Addenda
Protected Health Information. Readers should not Record to the healthcare providers (or any
confuse the common ACH usage of “remittance Receiver) if it is requested. The NACHA Operating
information” with the terms “remittance advice” Rules do not define how the information must be
or “electronic remittance advice (ERA)” as used delivered; rather, the delivery method to be utilized
in the health care industry to mean the detailed is determined between the financial institution and
explanation of benefits. the healthcare provider. Financial institutions may
offer a variety of methods to deliver the remittance
TRN Reassociation Trace Number data (e.g., fax, print and mail, email, Internet, or
The TRN Reassociation Trace Number is the key direct send) depending on their capabilities and
piece of information that the healthcare provider customer demand.
must have to tie the EFT payment to the ERA
and to update the patient payment records. The While not addressed within the NACHA Operating
identification of information contained in the Rules, NACHA recommends, as a best practice,
Payment Related Information field of the Addenda that RDFIs require a healthcare provider to enroll
record as part of the CORE-required Minimum only once in order to receive all of their CCD+
CCD+ Reassociation Data Elements will impact remittance information, applying the provider’s
financial institutions. During the EFT enrollment request to the receipt of all future CCD+ entries.
process, health plans will be required to instruct
healthcare providers to request the delivery of the
“CORE-required Minimum CCD+ Reassociation
Data Elements” from their financial institutions.
The CORE EFT & ERA Reassociation Rule will also
require healthcare providers to ask their financial
institutions for the “CORE-required Minimum
CCD+ Reassociation Data Elements.”

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG157
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

COMPARING THE ACH TRACE NUMBER Trace Number used by healthcare providers to tie
AND THE TRN REASSOCIATION TRACE the EFT payment to the ERA.
NUMBER
Figure 55-2 identifies the differences between the
ACH Trace Number and the TRN Reassociation

FIGURE 55-2

ASC X12 835 TRN

ACH TRACE NUMBER
REASSOCIATION TRACE NUMBER

CREATOR •  ODFI •  Health Plan/Payer

SOURCE •  NACHA CCD+ Field 11 of Entry Detail Record • HIPAA-adopted ASC X12N 005010X221 835, Table 1
TRN Reassociation Trace Number Segment (see Note 1
• The ACH Trace number is assigned by the ODFI as
below) TRN02-127 Trace Number
specified in the NACHA Operating Rules
• ASC X12 TRN Reassociation Trace number is placed
in the Payment Related Information field of the CCD+
Addenda Record (this number is assigned by the payer)

PRIMARY • Uniquely identifies each Entry within a batch in an ACH • Uniquely identifies the transaction set and aids in
FUNCTION input File reassociating payments and remittance advices that
have been separated.
• Source: HIPAA-adopted ASC X12N 005010X221 835

DELIVERY TO • Flows unchanged from the ODFI to the RDFI through • ASC X12 TRN Reassociation Trace Number is placed
HEALTHCARE the ACH Network in the CCD+ Addenda Record Payment Related
PROVIDER Information field; flows through the ACH Network
unchanged
• Flows unchanged from the payer to the ODFI, through
the ACH Network to the RDFI and ultimately to the
healthcare provider

OG158 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

ASC X12 835 TRN

ACH TRACE NUMBER
REASSOCIATION TRACE NUMBER

ISSUES • The ACH Trace Number is not used to reassociate the • When the CCD Entry does not include the Addenda
EFT and ERA; it is used primarily for customer service Record containing the Payment Related Information
and transaction research, and to aid in identifying field, the CCD cannot carry the ASC X12 TRN
returned transactions Reassociation Trace Number
• If a health plan creates an ACH Trace Number, it will • The NACHA Operating Rules require the RDFI to
be modified or overwritten by the ODFI to conform with provide the ASCX12 TRN Reassociation Trace Number
NACHA Operating Rules’ requirements and the ODFI’s in the CCD+ Payment Related Information field to the
numbering system healthcare provider by opening of business on the
2nd banking day after Settlement Date – if it has been
requested by the healthcare provider
• The NACHA Operating Rules do not specify how this
information is provided – healthcare providers should
contact their banks to arrange for the method and timing
of delivery.

STANDARDS •  NACHA •  ASC X12

DEVELOPMENT
ORGANIZATION

EXPLANATORY • TRN Reassociation Trace Number Segment (composed

NOTE 1 of 4 data elements) is sometimes referred to as:
   −  TRN 02 Reference ID Segment
   −  X12 TRN Segment
   −  Reassociation segment
   −  ERA TRN Trace Segment
   −  TRN segment

EXPLANATORY • The trace number in the TRN Reassociation Trace

NOTE 2 Number Segment described in Note 1 (TRN02-127
Trace Number) is sometimes referred to as:
   −  EFT Reference Number
   −  The Trace Number

EXPLANATORY The ACH Trace Number and the X12 TRN Reassociation Trace Number are NOT the same number.
NOTE 3

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG159
S E C T I O N V I – S p e c i a l To p i c s
C H A P T E R 5 5   H E A LT H C A R E E F T R E G U L AT I O N S A N D T H E A C H N E T W O R K

TRN REASSOCIATION TRACE NUMBER The following diagram provides information on

TECHNICAL SPECIFICATIONS the specific data elements that make up the TRN
Reassociation Trace Number as identified in the
The TRN Reassociation Trace Number is an EDI
ASC X12N/ Version 5010 TR3 Technical Report.
data segment that health plans include in both
The first three elements (Trace Type Code, the
the remittance advice (ERA) and the ACH CCD+
Reference Identification, and the Origination
Addenda Record. The EDI data segment contains
Company ID) are required; the last usage of the
both mandatory and optional Data Elements. The
Reference Identification is conditional and is not
data segment is designed to be a machine-readable
a required data element. Financial institutions
series of data elements that contains numbers and
may receive a Reassociation Trace Number with
asterisks (delimiters), followed by a back slash or
or without the last element (the 9999999 in Figure
a tilde (terminator). The TRN Reassociation Trace
55-3).
Number in the CCD+ must be an exact match
to the TRN Reassociation Trace Number in the
ERA and should be delivered to the healthcare
provider exactly as received by the financial
institution. No translation is necessary unless
specifically requested by the healthcare provider.

FIGURE 55-3  REQUIRED ELEMENTS OF THE REASSOCIATION TRACE NUMBER

Required Elements of the

Reassociation Trace Number

Trace Type Reference Origination Reference

TRN
* Code * Id * Company ID * ID
\

Reassociation Trace Number Example

TRN *1*12345*1512345678*9999999\

OG160 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX A   HISTORY OF THE ACH SYSTEM

of joint efforts by NACHA and the Federal Reserve

System, a project was implemented linking
SECTION VII ten local ACH Operators into an interregional

Appendices
exchange pilot project, with a goal of establishing
a nationwide ACH Network if the pilot project
proved a viable means of transferring funds.
By the end of 1977, the pilot had demonstrated
that the ACH would prove a workable means of
transmitting certain types of electronic payments
throughout the country. The next logical step was
APPENDIX A
the expansion of the program to provide for a
History of the ACH System coast-to-coast ACH Network. Arrangements were
made between NACHA and the Federal Reserve
System to implement an interregional exchange
The financial industry recognized the imperative system by the end of 1978. The ACH Network
need to improve the nation’s payments system in allowed a financial institution in one geographic
the late 1960s. Special task forces began to develop region to originate and/or receive entries from
a workable alternative to paper checks before the an ACH Operator in another geographic region.
volume became overwhelming. A direct result Processing arrangements and agreements had to
of the early groundwork was the establishment be in place prior to the handling of entries in this
of the first automated clearing house (ACH) for manner.
the exchange of paperless entries, the Calwestern
Automated Clearing House Association (CACHA), Significant changes have occurred since the initial
in 1972. At the same time, several other clearing development of the system. In 1979, format
house associations set up Special Committees on revisions to support Customer Initiated Entries
Paperless Entries (SCOPE) to implement similar (CIE) and Machine Transfer Entries (MTE) were
automated facilities. In most areas, agreements introduced to support new services. In 1981, an
were made between the local ACH associations Extended Processing Cycle, which permits a next-
and the Federal Reserve Bank serving the area day settlement with a later cutoff for Originators, was
to provide the facilities, equipment, and staff to implemented to provide for more rapid collection
operate an automated clearing house. of funds for corporate consolidation. This cycle
was initially restricted to debits and delayed ACH
As the number of ACH associations increased, files but was later expanded to support electronic
some elected to contract with the regional Federal return entries. Restrictions were later removed so
Reserve Bank or a private organization to operate any transaction could be processed in that cycle.
ACH processing facilities. Those ACH associations
that elected to operate their own facilities settled In 1982, NACHA sponsored a study in which
transactions through the local Federal Reserve Bank. corporations defined their needs for the movement
In 1974, the National Automated Clearing House of both funds and other data. As a result, the
Association (NACHA) was formed to coordinate NACHA Operating Rules were modified to support
the ACH movement nationwide. By 1978, there corporate transfers. These modifications permitted
were multiple ACH associations covering the entire multiple addenda records to be used with each
continental United States, operating under the funds transfer entry, thus enabling the Originator
standards established by NACHA. Alaska, Hawaii, to supply accounting and other information
Guam, and Puerto Rico are also served by ACH concerning the transaction to the Receiver.
associations.
The Corporate Trade Payment (CTP) format
For the most part, an ACH Operator processed was developed to permit the transmission of
entries on a local basis, serving the depository remittance information to the Receiver using a
financial institutions in its geographic area of fixed field format. During the same time frame in
responsibility. However, in early 1977, as a result which CTP was introduced, the American National

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG161
SECTION VII – Appendices
APPENDIX A   HISTORY OF THE ACH SYSTEM

Standards Institute’s (ANSI) Accredited Standards As NACHA moved through the 1990s, the use of ANSI
Committee (ASC) X12 was working to develop ASC X12 standards for electronic data interchange
electronic data interchange standards for common (EDI) became more popular among corporations.
business transactions and other transactions This increased popularity encouraged greater use
between corporate buyers and sellers. All ANSI of both the CCD and CTX formats. Both ODFIs
ASC X12 messages, including the X12.4 Payment and RDFIs began to offer a variety of services to
Order/Remittance Advice, use a variable length corporations for the processing of remittance data,
message with a broad data dictionary. Because on both the originating and receiving sides of the
the CTP format and X12.4 Payment Order/ ACH transaction.
Remittance Advice format were not compatible,
NACHA and ANSI committees met in 1985 to In 1992, a new application, the Death Notification
resolve these discrepancies. The ANSI ASC X12.4 Entry (DNE), was adopted to support the efforts
Payment Order/Remittance Advice was modified of the U.S. Department of the Treasury to allow
and additional fields were added to communicate a government agency (e.g., Social Security
information concerning the transfer of funds when Administration) to notify a financial institution
transmitting through several payment mechanisms. that the recipient of a government benefit payment
These new fields permitted an Originating has died. Also new in 1992, the Destroyed Check
Depository Financial Institution (ODFI) to convert Entry (XCK) application established the means for
the ASC X12.4 Payment Order/Remittance Advice a financial institution to utilize the ACH Network
to the CTP format. to facilitate the clearing of certain checks when
those checks have been inadvertently destroyed in
A new ACH transaction, called the Corporate Trade the check clearing process.
Exchange (CTX), was developed so the X12.4
data could accompany the funds transfer without In 1996, the Automated Enrollment Entry (ENR)
reformatting. The CTX format incorporated the was developed as an optional alternative to the
strengths of both the NACHA fixed record format paper enrollment methods used by many Federal
and the variable length record format of ASC X12. Government Agencies, enabling the ACH Network
The traditional 94-character fixed format was to be utilized by depository financial institutions
used in the Company/Batch Records so the funds to transmit consumer ACH credit enrollment
transfer could be executed with the ACH software information on behalf of their customers to Federal
already in place. A revised addenda record was Government Agencies. In 1998, the Automated
developed that continued the support of the Enrollment process was expanded to allow
94-character standard. However, 80 characters enrollments for both future ACH credit and ACH
of each addenda record were made available for debit transactions to be transmitted to Federal
payment related information. This innovation Government Agencies by DFIs on behalf of both
meant that the ANSI ASC X12.4 Payment Order/ consumers and businesses.
Remittance Advice could be transmitted via the
ACH delivery mechanism by using these payment- In 1997, the ACH Network was expanded to permit
related fields; the funds transfer could be effected; the transmission of Acknowledgment Entries
and the payment-related data could be delivered (ACK/ATX) by RDFIs, at their option, to indicate
to the receiving corporation in the X12.4 format. that corporate credit entries (CCD or CTX entries)
With this approach, the funds transfer, accounting, have been received by the RDFI and that the RDFI
and payment related information remain together. will attempt to post the payments to the Receivers’
As a result of the versatility of the CTX format, the accounts.
CTP format was eliminated in September 1996.
In 1998, the ACH Network began to accommodate
Point-of-Sale specifications, effective in 1985 and re-presented check entries, which allow for the
amended in 1988, allow the ACH to be used as a truncation and electronic collection of checks that
delivery mechanism for debit card transactions. are returned due to insufficient or uncollected
funds. In September 2000, a new Standard Entry

OG162 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX A   HISTORY OF THE ACH SYSTEM

Class Code, RCK, was implemented for this In 2006, the rules governing the ARC and POP
application. applications were further modified to enable
Originators to more readily identify business
In 1999, the ACH Network was further expanded checks that are ineligible for conversion to
to test the acceptance of two additional ACH debit electronic check transactions and exclude them
applications designed to facilitate the electronic from their ACH processing. Specifically, checks or
conversion/truncation of consumer check sharedrafts bearing an Auxiliary On-Us Field within
payments made either in-person at the point-of- the MICR line, and those checks or sharedrafts in
purchase (point of purchase entries) or delivered an amount greater than $25,000, became ineligible
to the Originator via the U.S. mail or at a dropbox for conversion to ARC and POP entries.
location (accounts receivable entries). These
debit applications, which required a consumer to In 2007, a new Standard Entry Class Code,
provide the merchant with a check from which the BOC (Back Office Conversion Entries), was
consumer’s bank routing and account information implemented, establishing the legal framework
would be drawn, provided Originators with an and technical specifications to enable retailers and
alternative to presenting the consumer’s check other merchants to accept checks for payment at
through the check clearing system. Short-term the point of purchase and convert those checks to
rules defining the legal framework and allowing ACH debit entries during back office processing.
testing for this type of check conversion/truncation
activity were established using the PPD format. In 2009, a new Standard Entry Class Code, IAT
(International ACH Transaction), was adopted to
In 2000, distinct rules and Standard Entry Class provide a more robust rules framework for the
Codes (CBR for Corporate Cross-Border Payment exchange of international payments via the ACH
and PBR for Consumer Cross-Border Payment) Network, replacing the earlier CBR and PBR
were implemented to facilitate the transmission applications. The Rules governing IAT entries
of payments internationally. Also in 2000, a new require clear identification of all international
SEC Code, POP (Point of Purchase Entries), was payment transactions transmitted via the ACH
implemented, establishing the legal framework Network and mandate the inclusion of specific
and unique technical specifications to support information defined within the Bank Secrecy Act’s
the conversion of checks presented at the point “Travel Rule” so that all parties to the transaction
of purchase and replacing the short-term rules for have the information necessary to comply with U.S.
this application. law, which includes the programs administered by
the Office of Foreign Assets Control (OFAC).
During 2001, two new Standard Entry Class
Codes, WEB (Internet-Initiated Entries) and TEL In response to the rapid growth and use of
(Telephone-Initiated Entries), became effective. mobile phones to access the Internet, the Internet-
These SEC Codes facilitate access to the ACH Initiated Entry (WEB) was enhanced in 2010 to
Network by providing Originators with additional include this communication channel. WEB is now
options (i.e., the Internet and the telephone) defined as an Internet-Initiated/Mobile Entry, and
for obtaining a Receiver’s authorization for ACH adds debit entries that are authorized or initiated
debit entries while, at the same time, heightening over the Internet using a mobile device to the WEB
security requirements for ACH entries authorized description.
via alternative media that bear a potentially greater
risk profile. Although the ACH Network has always provided
a channel for Originators to collect Return Fees
In 2002, a new Standard Entry Class Code, ARC electronically, the NACHA Operating Rules did not
(Accounts Receivable Entries), was introduced and always distinguish an ACH debit for the purpose
established a legal framework for the conversion of collecting a Return Fee from any other ACH
of consumer checks received by Originators via debit, nor were there explicit rules related to
the U.S. mail or at a dropbox location into ACH the origination of entries for such purposes. An
debit entries to consumers’ accounts. Originator was required to have obtained the

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG163
SECTION VII – Appendices
APPENDIX A   HISTORY OF THE ACH SYSTEM

Receiver’s explicit authorization in order to collect being able to identify a particular transaction as a
the fee via the ACH Network, with the general Return Fee and in reconciling his account, leading
requirement that the authorization be signed or to customer service inquiries for RDFIs. In 2010,
similarly authenticated by the Receiver. The manner these issues were addressed through rule changes
in which authorization was obtained depended specifically requiring authorization and transaction
upon the application used for the collection of the identification requirements for ACH debits used to
fee. A written authorization was required for a PPD collect Return Fees.
(or WEB if via the Internet); a return fee collected
by a TEL Entry would require a separate call and The chart in Appendix B of these Guidelines
compliance with the TEL rules. gives a brief overview of the Standard Entry Class
Codes currently used in the ACH Network, and a
By contrast, in a 2006 amendment to Regulation reference for more information.
E, the Federal Reserve Board clarified its position
allowing businesses to collect return fees via an
electronic funds transfer. To do so, a business
must provide notice to the customer that a one-
time return item fee will be collected electronically
from the customer’s account if an underlying
transaction is returned unpaid. As a result of this
revision to Regulation E, the Rules became more
restrictive than the regulation.

These differing requirements created challenges

for some businesses, particularly with respect to
checks, check conversion (ARC and BOC) and
check truncation transactions (RCK), where the
written authorization requirements for Return Fees
presented a burden to both merchants/billers and
customers alike. In order to use the ACH Network
to collect a return fee, an Originator would need to
first obtain written authorizations and signatures
in advance from all of its customers, when, on
average, only one percent of transactions are
returned unpaid. This represented a significant
customer service and trust issue, as well as a
logistical problem, for Originators. Similarly,
obtaining authorization for a fee after the customer’s
original payment has been returned unpaid was
challenging. As a result of this requirement of the
Rules, Originators and potential Originators of ACH
transactions often used other payment methods,
such as Remotely Created Checks, to collect return
fees.

To the extent that an Originator could use the

ACH Network to collect Return Fees, the Rules did
not require that these transactions be specifically
identified to the Receiver in any particular manner,
nor was there a means to relate the Return Fee to the
underlying transaction that was returned unpaid.
This presented challenges to a Receiver in terms of

OG164 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 APPENDIX B

Standard Entry Class Codes

STANDARD ENTRY CLASS CODES

STANDARD
TRANSACTION ACCOUNT AGREEMENT OR YEAR REFERENCES
ENTRY CLASS TITLE
TYPE TYPE AUTHORIZATION IMPLEMENTED IN GUIDELINES
(SEC) CODE
ACH Payment Non-Monetary N/A N/A 1997 Section V - Standard Entry Class Codes
ACK Acknowledge (Acknowledges CCD Chapter 36 - Acknowledgement Entries
Credit Entry)

2 0 1 3 O P E R AT I N G G U I D E L I N E S
Automated Accounting Non-Monetary N/A Agreement — ODFI/RDFI Section I - General Information
ADV Advice and ACH Operator Chapter 1 - Overview of the System

Accounts Receivable Entry Debit Consumer or Written Notice = 2002 Section V - Standard Entry Class Codes
ARC Non-Consumer Authorization Chapter 37 - Accounts Receivable Entries
Single Entry
Financial EDI Non-Monetary N/A N/A 1997 Section V - Standard Entry Class Codes
ATX Acknowledgement (Acknowledges CTX Chapter 36 - Acknowledgement Entries
Credit Entry)
Back Office Debit Consumer or Posted Notice and Written 2007 Section V - Standard Entry Class Codes
BOC Conversion Entry Non-Consumer Notice = Authorization Chapter 38 - Back Office Conversion Entries
Single Entry
Corporate Credit or Debit Credit or Debit Non-Consumer Agreement — Originator 1983 Section V - Standard Entry Class Codes
CCD Entry Single Entry or and Receiver Chapter 39 - Corporate Credit or Debit/Corporate
Recurring Entry Trade Exchange Entries
Customer Initiated Entry Credit Consumer Agreement — Originator 1979 Section V - Standard Entry Class Codes
CIE Originated and Receiver Chapter 40 - Customer Initiated Entries
Single Entry
Notification of Change or Non-Monetary Consumer or N/A 1980 ODFIs - Section II, Part One
Refused Notification of Non-Consumer Chapter 11
Change Originators - Section II, Part Two
COR
Chapter 19
RDFIs - Section II, Part Three
Chapter 28
Corporate Trade Credit or Debit Non-Consumer Agreement — Originator 1985 Section V - Standard Entry Class Codes
Exchange and Receiver Chapter 39 - Corporate Credit or Debit/Corporate
CTX
Single Entry or Trade Exchange Entries
Recurring Entry

OG165
SECTION VII – Appendices
A P P E N D I X B   S TA N D A R D E N T R Y C L A S S C O D E C H A R T
 STANDARD ENTRY CLASS CODES

OG166
STANDARD
TRANSACTION ACCOUNT AGREEMENT OR YEAR REFERENCES
ENTRY CLASS TITLE
TYPE TYPE AUTHORIZATION IMPLEMENTED IN GUIDELINES
(SEC) CODE
DNE Death Notification Entry Non-Monetary Consumer N/A 1992 Section V - Standard Entry Class Codes
(Federal Chapter 41 - Death Notification Entries
Government
Agency use
only.)
Automated Enrollment Entry Non-Monetary Non-Consumer Request by Receiver / 1996 Section V - Standard Entry Class Codes
SECTION VII – Appendices

(Federal RDFI use only Chapter 42 - Automated Enrollment Entries

ENR
Government
Agency)
International ACH Credit or Debit Consumer or Consumer Debit — in 2009 Section V - Standard Entry Class Codes
Transaction Non-Consumer writing and signed or Chapter 43 - International ACH Transaction Entries
Single Entry or similarly authenticated =
Recurring Entry authorization

Consumer Credit — orally

IAT
or other non-written means
= authorization

Corporate —
Agreement between
A P P E N D I X B   S TA N D A R D E N T R Y C L A S S C O D E C H A R T

Originator and Receiver.

Machine Transfer Entry Credit or Debit Consumer In writing and signed or 1979 Section I - General Information
similarly authenticated = Chapter 1 - Overview of the System
MTE
Single Entry authorization

Point-of-Purchase Entry Debit Consumer or Posted Notice and in 2000 Section V - Standard Entry Class Codes
Non-Consumer writing and signed or Chapter 44 - Point-of-Purchase Entries
POP
Single Entry similarly authenticated

Point-of-Sale Entry Debit Consumer In writing and signed or 1985 Section I - General Information
POS similarly authenticated Chapter 1 - Overview of the System
Single Entry
Prearranged Payment and Credit or Debit Consumer Consumer Debit — in 1975 Section V - Standard Entry Class Codes
Deposit writing and signed or Chapter 45 - Prearranged Payment and Depost
Single Entry or similarly authenticated. Entries
Recurring Entry
PPD
Consumer Credit — orally
or other non-written
means.

2 0 1 3 O P E R AT I N G G U I D E L I N E S
 STANDARD ENTRY CLASS CODES
STANDARD
TRANSACTION ACCOUNT AGREEMENT OR YEAR REFERENCES
ENTRY CLASS TITLE
TYPE TYPE AUTHORIZATION IMPLEMENTED IN GUIDELINES
(SEC) CODE
Re-presented Check Entry Debit Consumer Posted Notice = 2000 Section V - Standard Entry Class Codes
RCK authorization Chapter 46 - Re-presented Check Entries
Single Entry
Shared Network Transaction Debit Consumer Agreement — ODFI and Section I - General Information
SHR RDFI Chapter 1 - Overview of the System
Single Entry
Telephone-Initiated Entry Debit Consumer Orally authorized over 2001 Section V - Standard Entry Class Codes
telephone = authorization Chapter 47 - Telephone-Initiated Entries

2 0 1 3 O P E R AT I N G G U I D E L I N E S
TEL
Single Entry or
Recurring En try
Truncated Entry Debit Consumer or Agreement — ODFI and Section I - General Information
TRC Non-Consumer RDFI Chapter 1 - Overview of the System
Single Entry
Truncated Enties Exchange Debit Consumer or Agreement — ODFI and Section I - General Information
TRX Non-Consumer RDFI Chapter 1 - Overview of the System
Single Entry
Internet-Initiated/Mobile Debit Consumer In writing and signed or 2001 Section V - Standard Entry Class Codes
Entry similarly authenticated = Chapter 48 - Internet-Initiated/Mobile Entries
WEB Single Entry or authorization (Revised to add
Recurring Entry Mobile 2010)

Destroyed Check Entry Debit Consumer or N/A 1992 Section V - Standard Entry Class Codes
XCK
Non-Consumer Chapter 49 - Destroyed Check Entries

OG167
SECTION VII – Appendices
A P P E N D I X B   S TA N D A R D E N T R Y C L A S S C O D E C H A R T
SECTION VII – Appendices
APPENDIX C   ISSUES TO BE ADDRESSED IN THE AGREEMENT BETWEEN THE ODFI AND THE ORIGINATOR
OR THIRD-PARTY SENDER

APPENDIX C

Issues To Be Addressed in the Agreement Between the ODFI and

the Originator or Third-Party Sender

CONSUMER CORPORATE ISSUES THAT SHOULD BE DEFINED IN ORIGINATION AGREEMENT

BETWEEN ODFI AND ORIGINATOR OR THIRD-PARTY SENDER
DR. CR. DR. CR.
The nature, format and medium of Entries, or Entry information to be furnished
X X X X
by the Originator.

X X X X The place and time the Entries or Entry information is to be furnished by the Originator.

X X X X The Originator’s obligation to obtain valid authorization of Entries from Receivers.

The level of security to be established for delivering the payment data from the
X X X X Originator to the ODFI, such as transmittals with authorized signatures, the method
used to verify authenticity of telecommunicated data, etc.

X X X X Other data security and data breach provisions.

Responsibilities of the participating ODFI and Originator with respect to remaking

X X X X
Rejected Entries or Files.
The deadline for Reversals, corrections, or changes by the Originator of Entries or
X X X X
Entry information furnished to the ODFI.
The ODFI’s responsibility for delay by the ACH Operator or RDFI in processing any
X X X X credit or debit the DFI Transmits to the ACH Operator, or failure to process or credit or
debit any such Entry or other acts of omission of a third party.

X X X X Whether the Origination Agreement covers credit or debit Entries or both.

X X X X Any restrictions on the types of ACH Entries that may be originated.

X X The time when the funds may be available to the Originator.

X X The time when funds are to be provided to the ODFI by the Originator.

The charges or fees by the ODFI for providing services to the Originator under the
X X X X
Origination Agreement.

X X X X Exposure limits for the Originator.

Responsibilities of the ODFI and Originator with respect to handling Returns,

X X X X
Notifications of Change, dishonored Returns, and refused Notifications of Change.

X X X X The conditions under which a Third-Party Service Provider will be utilized.

Procedures for terminating the Origination Agreement and time frames under which the
X X X X
processing of Entries under that Origination Agreement will cease.

X X X X The right of the ODFI to terminate or suspend an agreement for breach of the Rules.

X X X X The Originator’s obligation regarding Prenotifications, if Prenotification process is used.

OG168 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX C   ISSUES TO BE ADDRESSED IN THE AGREEMENT BETWEEN THE ODFI AND THE ORIGINATOR
OR THIRD-PARTY SENDER

CONSUMER CORPORATE ISSUES THAT SHOULD BE DEFINED IN ORIGINATION AGREEMENT

BETWEEN ODFI AND ORIGINATOR OR THIRD-PARTY SENDER
DR. CR. DR. CR.
The Originator’s obligation to obtain, retain, and provide copies of authorizations,
X
particularly with regard to consumer authorizations under Regulation E.
The Originator’s obligation with respect to consumer alleged errors, including under
X
Regulation E.
The right of, and procedures for, the ODFI to audit an Originator for compliance with
X X X X
the Origination Agreement and the Rules.

X X X X Record retention requirements.

X X X X Use of proper authorization methods, authorization forms, and ACH formats.

The use of appropriate encryption standards for ACH Entries involving banking
X X X X
information that is Transmitted or exchanged via an Unsecured Electronic Network.
Responsibilities of the ODFI and Originator with respect to handling Acknowledgment
X
Entries, if such transactions are desired by the Originator.
An acknowledgment by the Originator that ACH transactions it originates comply with
X X X X
the provisions of U.S. law.
The Originator’s responsibility for matters warranted or agreed by the ODFI in the Rules
X X X X pertaining to Entries exchanged through the ACH Network, which may vary depending
on the Entry Type.
For International ACH Transactions, (IAT entries),
• The terms and conditions for the allocation of gains, losses and the assumption
X X X X
of risk for foreign exchange conversion.
• The rights and responsibilities of the ODFI in the event of an Erroneous Entry.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG169
 APPENDIX D

OG170
Document Retention Schedule

DOCUMENT RETENTION SCHEDULE

ACH OPERATOR ORIGINATOR PARTICIPATING DFI COPY PROVISIONS RULES REFERENCE
SECTION VII – Appendices

Record of Entries One Year from Date Six Years from Date Operator or DFI - provide copy of Operator - Article Four,
Received or of Entry of Entry information relating to Entry if requested Section 4.5
Transmitted by DFI or other ACH Operator.
DFI - Article One, Subsection 1.4.1 & 1.4.2
Authorizations Two Years from Originator - provide copy to ODFI in order Article Two, Subsection 2.3.2.5
Termination or for the ODFI to provide to the requesting
Revocation of RDFI within ten Banking Days of request.
Authorization
Eligible Source Two Years from Originator - provide copy of front of Article Two, Subsection 2.5.1.5 (ARC)
Document for ARC & Settlement Date of Entry source document to ODFI in order for the
BOC (front only) ODFI to provide to the requesting RDFI Article Two, Subsection 2.5.2.5 (BOC)
within ten Banking Days of request made
APPENDIX D  DOCUMENT RETENTION SCHEDULE

within two years of Entry.

Eligible Item to Which Seven Years from Originator - provide copy of the related Article Two, Subsection 2.5.13.5
RCK Entry Relates Settlement Date of item to ODFI in order for the ODFI to
Entry (front & back of provide to the requesting RDFI within ten
related item) Banking Days of request.
Copy or Image of Item Six Years from Date ODFI - provide coy of the related item to Article Two, Subsection 2.5.18.4
to Which XCK Entry of Entry the requesting RDFI within thirty days of
Relates written request made within six years of
initiation date of the XCK Entry.
Written Statement of One Year from RDFI - provide copy within ten Banking Article Three,
Unauthorized Debit Settlement Date of Days of request by ODFI if made within Subsection 3.12.5
Related Extended one year of Entry date.
Return Entry

2 0 1 3 O P E R AT I N G G U I D E L I N E S
 APPENDIX E

Source Document Eligibility Charts

ELIGIBLE SOURCE DOCUMENT, PRESENTMENT, AND AUTHORIZATION REQUIREMENTS

FOR ARC, BOC, POP, AND RCK ENTRIES
Source
Source Source Document
Source Document Document
Document Must Must Have A Routing Number,
Must Contain A Must Be Source Document Authorization
Be In An Amount Account Number, And Notes
Pre-Printed Check Completed (Check) Presentment Requirements

2 0 1 3 O P E R AT I N G G U I D E L I N E S
Of $25,000 Check Serial Number
Serial Number And Signed
Or Less Encoded In Magnetic Ink
By Receiver
Eligible Source Document Notice to Receiver Originator must use
via U.S. mail or dropbox. a reading device to
As of March 16, 2012, also capture the MICR line
ARC     via a delivery service or in from the check.
person for payment of a
bill at a manned location.
Eligible Source Document Notice to Receiver Originator must use
at point-of-purchase or and copy of notice or a reading device to
manned bill payment similar language to capture the MICR line
BOC     location for conversion Receiver at time of from the check.
during back-office transaction
processing
Originator must Eligible Source Document Notice to Receiver Source document is
use a reading at point-of-purchase or and copy of notice voided and returned to
device to capture manned bill payment or similar language the Receiver.
POP   the MICR line  location to Receiver at time
from the blank of transaction and a Source document has
check written authorization not been used for a prior
from the Receiver POP entry.
Must be in an An RCK is used to collect Notice to the Check is dated 180 days
amount less than the amount of a check that Receiver of the or less from the date of
$2,500 has been returned NSF or terms for initiating an the RCK entry.
uncollected funds RCK entry prior to
receiving the source Consumer accounts
RCK    document to which only.
the RCK relates
2 times as a check,
1 time as RCK or
1 time as a check and
2 times as RCK.

OG171
APPENDIX E   SOURCE DOCUMENT ELIGIBILITY CHARTS
SECTION VII – Appendices
 INELIGIBLE SOURCE DOCUMENTS FOR ARC, BOC, POP, AND RCK ENTRIES

OG172
Check
Check That Check That Is An Check Drawn
Check Drawn On An Check Drawn On Check
Check Draft That Accesses Obligation Of A On The Treasury
Contains Investment A State Or Local Payable In
Payable Does Not Credit Card Financial Institution Of The United
Auxillary Company (As Government That A Medium
To Person Contain Account, Home (e.g. Official Check, States, A Federal
On-Us Field Defined In The Is Not Payable Other Than
Other Than Signature Of Equity Line, Or Cashier’s Check, Reserve Bank, Or
In The Micr Investment Through Or At A United States
Originator Receiver Other Form Of Travelers Check, A Federal Home
Line Company Act Participating DFI Currency
Credit Money Order) Loan Bank
Of 1940)
SECTION VII – Appendices

ARC         

BOC         

Check is
not required
to contain
POP        
signature, but
APPENDIX E  SOURCE DOCUMENT ELIGIBILITY CHARTS

cannot be a
paper draft

RCK         

2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
A P P E N D I X F   S A M P L E A U T H O R I Z AT I O N F O R D I R E C T D E P O S I T

APPENDIX F

Sample Authorization for Direct Deposit and Split Deposit via ACH
(ACH Credit)

CONSUMER AUTHORIZATION FOR DIRECT DEPOSIT VIA ACH

(ACH CREDITS)
Direct Deposit via ACH is the deposit of funds to a consumer’s account for payroll, employee expense
reimbursement, government benefits, tax and other refunds, and annuities and interest payments.
Check all that apply:   Begin Deposit    Change Information    Split Among Multiple Accounts
I have provided information for each of my accounts below.

I (we) hereby authorize ____________________

[Company Name] (“COMPANY”) to electronically credit my (our) account
(and, if necessary, to electronically debit my (our) account to correct erroneous credits1) I (we) agree that
ACH transactions I (we) authorize comply with all applicable law.
Account #1
 Checking Account/ Savings Account (select one) at the depository financial institution
(“DEPOSITORY”) named below.
Depository Name_________________________________
Routing Number__________________ Account Number_____________________________________________
Name(s) on the Account________________________________________________________________________
Amount of credit (i.e., flat amount or percentage) ________________________________________________
Date(s) and/or frequency of credit(s)____________________________________________________________
Account #2
 Checking Account/ Savings Account (select one) at the depository financial institution
(“DEPOSITORY”) named below.
Depository Name_________________________________
Routing Number__________________ Account Number_____________________________________________
Name(s) on the Account________________________________________________________________________
Amount of credit (i.e., flat amount or percentage) ________________________________________________
Date(s) and/or frequency of credit(s)____________________________________________________________
Account #3
 Checking Account/ Savings Account (select one) at the depository financial institution
(“DEPOSITORY”) named below.
Depository Name_________________________________
Routing Number__________________ Account Number_____________________________________________
Name(s) on the Account________________________________________________________________________
Amount of credit (i.e., flat amount or percentage) ________________________________________________
Date(s) and/or frequency of credit(s)____________________________________________________________
I (we) understand that this authorization will remain in full force and effect until I (we) notify COMPANY
[insert manner of revocation, i.e., in writing, by phone, location, address, etc.] that I (we) wish to revoke
this authorization. I (we) understand that COMPANY requires at least [X days/weeks] prior notice in
order to cancel this authorization.2
Name(s)______________________________________________________________________________________
(Please Print)

Date___________ Signature(s)___________________________________________________________________

1
The NACHA Operating Rules do not require the consumer’s express authorization to initiate Reversing Entries to correct
erroneous transactions. However, Originators should consider obtaining express authorization of debits or credits to correct
errors.
2
Written credit authorizations must provide that the Receiver may revoke the authorization only by notifying the Originator in
the time and manner stated in the authorization. The reference to notification should be filled with a statement of the time and
manner that notification must be given in order to provide company a reasonable opportunity to act on it (e.g., “In writing by
mail to 100 Main Street, Anytown, NY that is received at least three (3) days prior to the proposed effective date of the termination
of authorization”).

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG173
SECTION VII – Appendices
A P P E N D I X G   S A M P L E A U T H O R I Z AT I O N F O R D I R E C T PAY M E N T

APPENDIX G

Sample Authorization for Direct Payment via ACH (ACH Debit)

CONSUMER AUTHORIZATION FOR DIRECT PAYMENT VIA ACH

(ACH DEBITS)

Direct Payment via ACH is the transfer of funds from a consumer account for the purpose
of making a payment.

I (we) authorize __________________________

[Company Name] (“COMPANY”) to electronically debit my (our) account
(and, if necessary, electronically credit my (our) account to correct erroneous debits1) as follows:

 Checking Account/   Savings Account (select one) at the depository financial institution named below
(“DEPOSITORY”). I (we) agree that ACH transactions I (we) authorize comply with all applicable law.

Depository Name_________________________________

Routing Number__________________ Account Number_____________________________________________

Amount of debit(s) or method of determining amount of debit(s) [or specify range of acceptable dollar
amounts authorized]: _________________________________________________.

Date(s) and/or frequency of debit(s): _________________________________________________.

I (we) understand that this authorization will remain in full force and effect until I (we) notify COMPANY
[insert manner of revocation, i.e., in writing, by phone, location, address, etc.] that I (we) wish to revoke
this authorization. I (we) understand that COMPANY requires at least [X days/weeks] prior notice in
order to cancel this authorization.2

Name(s)______________________________________________________________________________________
(Please Print)

Date___________ Signature(s)___________________________________________________________________

1
The NACHA Operating Rules do not require the consumer’s express authorization to initiate Reversing Entries to correct
erroneous transactions. However, Originators should consider obtaining express authorization of debits or credits to correct
errors.
2
Written debit authorizations must provide that the Receiver may revoke the authorization only by notifying the Originator in
the time and manner stated in the authorization. The reference to notification should be filled with a statement of the time and
manner that notification must be given in order to provide company a reasonable opportunity to act on it (e.g., “In writing by
mail to 100 Main Street, Anytown, NY that is received at least three (3) days prior to the proposed effective date of the termination
of authorization”).

OG174 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
A P P E N D I X H   G U I D E L I N E S F O R C O N S U M E R A U T H E N T I C AT I O N

APPENDIX H

Guidelines for Consumer Authentication

GUIDELINES FOR CONSUMER AUTHENTICATION

[All SEC code references are for consumer debit transactions]

INTERNET/ONLINE
TELEPHONE1
NETWORK
Minimum Acceptable
Who Initiates Call? Minimum Acceptable Authentication
Authentication
RECURRING
Existing Relationship2 Similarly authenticate using Consumer (Receiver) or Option 1 (Confirmation of a previously-provided written
a method compliant with Company (Originator) authorization document): Similarly authenticate written terms
E-Sign4 and that evidences of authorization previously delivered to a consumer (Receiver)
the consumer’s (Receiver’s) using a method that evidences the consumer’s identity and
identity and assent to the assent to the authorization
authorization
Example: Written terms of the authorization have previously
Example: Consumer enters been delivered to the consumer in explanation of telephone
a digital signature, PIN, payment option. Consumer (Receiver) authenticates
password or shared secret to agreement to the terms of authorization by key-entering into
authorize the Entry.3 a VRU or speaking into a recorded line a PIN that identifies
the consumer.
SEC Code: WEB
SEC Code: PPD

Option 2 (Fully telephone-based authorization with written

confirmation): Originator must use commercially reasonable
procedures to authenticate the Receiver. The terms of the
authorization and the consumer’s (Receiver’s) consent are
provided orally, but to satisfy Regulation E must be recorded
and a confirming copy must be provided to the Receiver in
writing.

Example: Consumer (Receiver) calls telephone bill payment

line to pay an existing invoice. The customer service
representative confirms the consumer’s identity by verifying
certain account details, offers the consumer the opportunity to
have invoices automatically debited each month and reads to
the consumer the terms of the authorization. The consumer
affirmatively states his/her authorization and provides his/her
account details for payment. The line is recorded, and the
Originator sends a copy of the authorization to the consumer
prior to the Settlement Date of the Entry.

SEC Code: TEL

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG175
SECTION VII – Appendices
A P P E N D I X H   G U I D E L I N E S F O R C O N S U M E R A U T H E N T I C AT I O N

INTERNET/ONLINE
TELEPHONE1
NETWORK
Minimum Acceptable
Who Initiates Call? Minimum Acceptable Authentication
Authentication
No Relationship Similarly authenticate using Consumer (Receiver) Option 1 (Confirmation of a previously-provided written
a method compliant with authorization document): Similarly authenticate written terms
E-Sign4 and that evidences of authorization previously delivered to a consumer (Receiver)
the consumer’s (Receiver’s) using a method that evidences the consumer’s identity and
identity and assent to the assent to the authorization
authorization
Example: Terms of the authorization are delivered to the
Example: Originator verifies consumer in a catalog mailed on an unsolicited basis.
identity in a commercially Consumer (Receiver) authenticates agreement to the terms
reasonable manner using an of authorization by key-entering into a VRU or speaking into a
identity database.3 recorded line a PIN printed in the catalog.

SEC Code: WEB SEC Code: PPD

Option 2 (Fully telephone-based authorization with written

confirmation): Originator must use commercially reasonable
procedures to authenticate the Receiver. The terms of the
authorization and the consumer’s (Receiver’s) consent are
provided orally, but to satisfy Regulation E must be recorded
and a confirming copy must be provided to the Receiver in
writing.

Example: Consumer (Receiver) calls to order a monthly billed

magazine in response to an unsolicited mailing. The customer
service representative confirms the consumer’s identity, offers
the consumer the opportunity to be automatically debited
for the monthly subscription fee and reads to the consumer
the terms of the authorization. The consumer affirmatively
states his/her authorization and provides his/her account
details for payment. The line is recorded, and the Originator
sends a copy of the authorization to the consumer prior to the
Settlement Date of the Entry.

SEC Code: TEL

Company (Originator) Similarly authenticate written terms of authorization previously

delivered to a consumer (Receiver) using a method that
evidences the consumer’s identity and assent to the
authorization

Example: Terms of the authorization are delivered to the

consumer in a catalog mailed on an unsolicited basis.
Consumer (Receiver) authenticates agreement to the terms
of authorization by key-entering into a VRU or speaking into a
recorded line a PIN printed in the catalog with the authorization
language.5

SEC Code: PPD

OG176 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
A P P E N D I X H   G U I D E L I N E S F O R C O N S U M E R A U T H E N T I C AT I O N

INTERNET/ONLINE
TELEPHONE1
NETWORK
Minimum Acceptable
Who Initiates Call? Minimum Acceptable Authentication
Authentication
NON-RECURRING
Existing Relationship2 Similarly authenticate using Consumer (Receiver) or Option 1 (Confirmation of a previously-provided written
a method compliant with Company (Originator) authorization document): Similarly authenticate written terms
E-Sign4 and that evidences of authorization previously delivered to a consumer (Receiver)
the consumer’s (Receiver’s) using a method that evidences the consumer’s identity and
identity and assent to the assent to the authorization
authorization
Example: Terms of the authorization are delivered to the
Example: use of a digital consumer in a catalog mailed on an unsolicited basis.
signature, PIN, password or Consumer (Receiver) authenticates agreement to the terms
shared secret3 of authorization by key-entering into a VRU or speaking into a
recorded line a PIN printed in the catalog.
SEC Code: WEB
SEC Code: PPD

Option 2 (Fully telephone-based authorization with written

confirmation): Originator must use commercially reasonable
procedures to authenticate the Receiver; the terms of the
authorization and the consumer’s (Receiver’s) consent are
provided orally, but must be recorded or a confirming copy
must be provided to the Receiver in writing.

Example: Consumer (Receiver) calls telephone bill payment

line to pay an existing invoice. The customer service
representative confirms the consumer’s identity by verifying
certain account details and reads to the consumer the terms
of the authorization. The consumer affirmatively states his/her
authorization and provides his/her account details for payment.
The line is recorded, or the Originator sends a copy of the
authorization to the consumer prior to the Settlement Date of
the Entry.

SEC Code: TEL

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG177
SECTION VII – Appendices
A P P E N D I X H   G U I D E L I N E S F O R C O N S U M E R A U T H E N T I C AT I O N

INTERNET/ONLINE
TELEPHONE1
NETWORK
Minimum Acceptable
Who Initiates Call? Minimum Acceptable Authentication
Authentication
No Relationship Similarly authenticate using Consumer (Receiver) Option 1 (Confirmation of a previously-provided written
a method compliant with authorization document): Similarly authenticate written terms
E-Sign4 and that evidences of authorization previously delivered to a consumer (Receiver)
the consumer’s (Receiver’s) using a method that evidences the consumer’s identity and
identity and assent to the assent to the authorization
authorization
Example: Terms of the authorization are delivered to the
Example: Originator verifies consumer in a catalog mailed on an unsolicited basis.
identity in a commercially Consumer (Receiver) authenticates agreement to the terms
reasonable manner using an of authorization by key-entering into a VRU or speaking into a
identity database.3 recorded line a PIN printed in the catalog.

SEC Code: WEB SEC Code: PPD

Option 2 (Fully telephone-based authorization with written

confirmation): Originator must use commercially reasonable
procedures to authenticate the Receiver; the authorization
must be recorded or a confirming copy must be provided to the
Receiver in writing.

Example: Consumer (Receiver) calls a telephone order

line in response to an advertisement. The customer service
representative confirms the consumer’s identity by verifying
certain personal information and reads to the consumer the
terms of the authorization. The consumer affirmatively states
his/her authorization and provides his/her account details for
payment. The line is recorded, or the Originator sends a copy
of the authorization to the consumer prior to the Settlement
Date of the Entry.

SEC Code: TEL

Company (Originator) Similarly authenticate written terms of authorization previously
delivered to a consumer (Receiver) using a method that
evidences the consumer’s identity and assent to the
authorization.

Example: Terms of the authorization are delivered to the

consumer in a catalog mailed on an unsolicited basis.
Consumer (Receiver) authenticates agreement to the terms
of authorization by key-entering into a VRU or speaking into a
recorded line a PIN printed in the catalog.5

SEC Code: PPD

1
 he Originator must retain a record of any authentication code provided by the consumer. If the consumer verbally expresses the authentication
T
code, the consumer’s statement of the code must be recorded. Consider the following best practices when using the telephone to similarly
authenticate: Code should be a minimum of four digits; if there is no existing relationship between the Originator and Receiver, the code should
be printed on the written authorization form that is in the consumer’s possession when this telephone conversation occurs in order to demonstrate
the consumer’s possession of the authorization language. Please note that many telephone authorizations are also subject to the Federal Trade
Commission’s Telemarketing Sales Rule, 16 C.F.R. Part 310.
2
 here is an Existing Relationship when there is a written agreement in place between the Originator and the consumer, or when the consumer has
T
purchased goods or services from the Originator in the past two years.
3
Must be encrypted with a minimum of 128-bit RC4 encryption technology or equivalent technology.
4
The Electronic Signatures in Global and National Commerce Act (15 U.S.C. 7001 et seq).
5
 utbound calls by an Originator to a consumer where there is no prior relationship pose heightened risks for obtaining a properly authenticated,
O
bona fide authorization. Originators in such circumstances should pay particular attention to compliance with the Telemarketing Sales Rule and
should take steps to ensure that their authorization language is clear, conspicuous and readily understood by the Receiver, and that their means of
authentication unambiguously indicates the Receiver’s assent to the transaction. The TEL code cannot be used in this situation.

OG178 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX J  BASIC ASC X12 RULES

Each of the three areas of the payment-related

APPENDIX J
transaction set consists of data segments, which
Basic ASC X12 Rules may be mandatory or optional. Data segments
are made up of smaller components called data
elements, which may be mandatory, optional, or
The NACHA Operating Rules support a number relational. Data elements are fixed or variable
of payment formats that may be accompanied by in length. Minimum and maximum values are
addenda records utilizing payment related ANSI ASC provided for variable-length elements.
X12 transaction sets or data segments: PPD, CCD,
CIE, and CTX. The standards for these transaction Note: The diagram in Figure J-1 illustrates the
sets (currently, 103 Abandoned Property Filings structure of an X12 message containing multiple
[known as the 103 Transaction Set]; 521 Income Functional Envelopes within the Interchange
or Asset Offset [known as the 521 Transaction Envelope and multiple like-Transaction Sets within
Set]; 813 Electronic Filing of Tax Return [known a Functional Envelope. Although ASC X12 allows
as the 813 Transaction Set]; 820 Payment Order/ this structure, the NACHA Operating Rules allow
Remittance Advice [known as the 820 Transaction only one such envelope per CTX entry. (This
Set]; 823 Lockbox [known as the 823 Transaction limitation applies to the ISA/IEA, GS/GE and ST/
Set]; and 835 Health Care Claim Payment/ SE segments.)
Advice [known as the 835 Transaction Set]) were
developed by the Accredited Standards Committee
X12, a standards development committee formally
chartered by the American National Standards
Institute (ANSI). The ASC X12 Committee consists
of corporations, financial institutions, trade
associations, government agencies, and other
organizations interested in the development and
increased use of Electronic Data Interchange (EDI),
the exchange of business transaction information
in machine readable format.

X12 TRANSACTION STRUCTURE

Figure J-1 illustrates the structure of an ASC X12
transaction. Of principal interest is the transaction
set envelope of the message, which carries the
detailed data segments of the payment-related
ANSI ASC X12 transaction set (i.e., 103 Abandoned
Property Filing, 521 Income or Asset Offset,
813 Electronic Filing of Tax Return Data, 820
Payment Order/Remittance Advice, 823 Lockbox,
or 835 Health Care Claim Payment/Advice). The
transaction set envelope consists of three areas:

• the header area;

• the detail area; and
• the summary area.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG179
SECTION VII – Appendices
APPENDIX J   BASIC ASC X12 RULES

of this envelope is defined by the ASC X12

Communications Transport Protocol
Interchange Control Structures.
Interchange Control Header
ISA • GS/GE
Functional Group Header  Within the ISA/IEA envelope is a “Functional
GS
Group” Envelope with a Functional Group
Transaction Set Header
ST Header (GS) and a Functional Group Trailer (GE).
The identifications used in the GS/GE envelope
Detail Data are different from those in the ISA/IEA in that
Segments
they identify the point of application at both

FUNCTIONAL GROUP
the originating and receiving companies. The
Transaction Set Trailer
SE structure of this envelope is defined by the ASC
Transaction Set Header
X12 Application Control Structure. Collectively,
ST

COMMUNICATIONS SESSION
the headers and trailers of these two segments
INTERCHANGE ENVELOPE allow data to be segregated logically for easy
Detail Data
interpretation by the receiver.
Segments

• ST/SE (ANSI ASC X12 transaction sets

Transaction Set Trailer
SE containing a BPR or BPS data segment [i.e.,
Functional Group Trailer 103, 521, 813, 820, 823, or 835 Transaction
GE
Sets], and payment related UN/EDIFACT
Functional Group Header
GS Standards)
The innermost envelope is the “transaction set,”
FUNCTIONAL GROUP

Transaction Set Header

ST
which begins with the Transaction Set Header
Detail Data (ST) and ends with the Transaction Set Trailer
Segments (SE). The transaction set structure is defined by
an ANSI ASC X12 transaction set containing a
SE
Transaction Set Trailer BPR or BPS data segment (i.e., 103 Transaction
Set, 521 Transaction Set, 813 Transaction Set,
Functional Group Trailer
GE 820 Transaction Set, 823 Transaction Set, or
Interchange Control Trailer 835 Transaction Set), or payment related UN/
IEA
EDIFACT syntax. The 820 Transaction Set, the
Communications Transport Protocol 835 Transaction Set, and the 813 Transaction Set
contain detailed data segments that are used to
FIGURE J-1 define purchase order and remittance advice
information, explanation of benefits (EOB)
remittance advice information, and electronic
tax filing remittance information, respectively.
ANSI ASC X12 ENVELOPING
The 521 Transaction Set is used for income
STRUCTURES
or asset offsets, and the 823 Transaction Set
The X12 message consists of three envelopes accommodates lockbox processing. The 103
outside of the detailed data segments. Transaction Set is used for abandoned property
filings.
• ISA/I6EA
 The outermost envelope is an “Interchange (Note: With CTX entries, each of the three
Control” Envelope which consists of an envelopes may only be used once. Although ASC
Interchange Control Header (ISA) and an X12 does allow multiple Functional Envelopes
Interchange Control Trailer (IEA). The ISA/ within the Interchange Envelope and multiple
IEA Interchange Segments are used to identify like-Transaction Sets within a Functional Envelope,
the Originator and the receiver of a physical the NACHA Operating Rules allow only one such
transmission (point-to-point). The structure

OG180 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX J  BASIC ASC X12 RULES

envelope per CTX entry. This limitation applies to (01 to 12), and DD is the day in the month (01
the ISA/IEA, GS/GE and ST/SE envelopes.) to 31).

X12 DATA SEGMENT REQUIREMENT R – Decimal Number

Data segments within the Interchange Control A decimal data element contains an explicit decimal
Structures, the Application Control Structure, and point and is used for numeric values that have a
the ANSI ASC X12 transactions sets containing a varying number of decimal positions. The decimal
BPR or BPS data segment (the 103 Transaction point always appears in the character stream if
Set, the 521 Transaction Set, the 813 Transaction the decimal point is at any place other than the
Set, the 820 Transaction Set, the 823 Transaction right end. If the value is an integer (decimal point
Set, or the 835 Transaction Set) will have one of at the right end), the decimal point should be
the following two designators which define their omitted. For negative values, the leading minus
requirement: sign (-) is used. Absence of a sign indicates a
positive value. The plus sign (+) should not be
1. M
 andatory (M) – This data segment must be transmitted. Leading zeros should be suppressed
present in the transaction set. unless necessary to satisfy a minimum length
requirement. Trailing zeros following the decimal
2. O
 ptional (O) – The appearance of this segment point should be suppressed unless necessary to
in the transaction set is either at the option of indicate precision. The use of triad separators (for
the sending party or is based on the mutual example, the commas in 1,000,000) is expressly
agreement of the interchange parties. prohibited. The length of a decimal type data
element does not include the optional leading sign
DATA ELEMENT REQUIREMENT or decimal point.

Data elements within a particular data segment The following is an example of a $100.00 positive
will have one of the following three types of integer value in the BPR data segment for the
designators which define their requirement within “Monetary Amount” data element (variable length
that segment: of one to fifteen characters):

1. M
 andatory (M) – The data element must be *100*
present in the segment (presence means a data
element must not be empty). The next example illustrates a $100.02 fractional
value in the same data segment and data element:
2. O
 ptional (O) – This element may or may not
be used, depending on the requirements of the *100.02*
Originator. Optional fields not used will be
flagged by an “*”. ID – Identifier
An identifier data element always contains a value
3. R
 elational (X) – Relational conditions may exist
from a predefined list of values that is maintained
among two or more data elements within the
by the X12 Committee or some other body
same data segment based on the presence or
recognized by the X12 Committee. Trailing spaces
absence of one of those elements.
should be suppressed unless necessary to satisfy
minimum length.
DATA ELEMENT TYPES
Data element types are described as follows: Nn – Numeric
A numeric data element is represented by one
DT – Date or more digits with an optional leading sign
A date data element is used to express the ISO representing a value in the normal base 10. The
standard date in YYMMDD format in which YY is value of a numeric data element includes an implied
the year in the century (00 to 99), MM is the month decimal point. It is used when the position of

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG181
SECTION VII – Appendices
APPENDIX J   BASIC ASC X12 RULES

the decimal point within the data is permanently following the Monetary Amount (782), or $2,000,
fixed and is not to be transmitted with the data. the segment is terminated using a backslash.
The data element dictionary defines the number
of implied decimal positions. The representation One use of CTX is for the RDFI to send the
for this data element type is Nn where N indicates receiving corporation pure X12 information that
that it is numeric and n indicates the number of has been stripped from the CTX addenda records.
decimal positions to the right of the fixed implied This requires less time and effort than reformatting
decimal point. For negative values, the leading the information into another industry standard.
minus sign (-) is used. Absence of a sign indicates To retrieve the pure X12 message from the CTX
a positive value. The plus sign (+) should not be transaction, the RDFI will need to:
transmitted. Leading zeros should be suppressed
unless necessary to satisfy a minimum length • insert the Settlement Date in the DTM segment
requirement. The length of a numeric type data (translating the Julian date in the ACH batch
element does not include the optional sign. header to a YYMMDD format);

AN – String • detach the addenda from the entry detail record;

A string data element is a sequence of any and
characters. The characters shall be left justified and
• strip away the ACH addenda record type code,
shall be space filled. Leading spaces, when they
the addenda type code, addenda sequence
occur, are presumed to be significant characters.
number, and the entry detail sequence number.
Trailing spaces should be suppressed unless they
are necessary to satisfy minimum length.
Addenda record that accompany a CCD or PPD
entry may carry up to 80 characters of information
TM – Time
formatted in a valid ANSI ASC X12 data segment.
A time data element is used to express the ISO The segments most widely used with the CCD
standard time in HHMMSSd..d format in which HH and PPD addenda records will be the REF, RMR,
is the hour for a 24 hour clock (00 to 23), MM is NTE, and DTM data segments or NACHA endorsed
the minutes (00 to 59), SS is the seconds (00 to 59), banking conventions.
and d..d is decimal seconds.
As an example, the NTE data segment permits free
After the Originator has provided all of the form information or data for comment or special
elements needed in a segment, the segment can instruction. An NTE segment for a late payment
be terminated. For example, the following is a could appear as follows:
remittance segment relating to an invoice, number
022. The total amount of the invoice is $2,000.00. NTE past due payment/

RMR*IV*022**2000.00\ Note: For CCD payments, the following payment

related ANSI ASC X12 data segments (i.e., from
The following is the actual RMR Segment to which the ASC X12 103 Transaction Set, 521 Transaction
the example can be compared: Set, 813 Transaction Set, 820 Transaction Set, 823
Transaction Set, or 835 Transaction Set) will not be
RMR*Reference Number Qualifier*Reference used in the addenda record:
Number*Payment Action Code*Monetary
Amount*Total Invoice Credit/Debit ST (Transaction Set Header)
Amount*Discount Amount Taken\
BPR (Beginning Segment Payment Order/
Note: The addition of the second asterisk showing Remittance Advice)
the omission of the Payment Action Code element
(482) demonstrates an optional field not used. CUR (Currency)
Rather than indicating the omission of the elements
SE (Transaction Set Trailer)

OG182 2 0 1 3 O P E R AT I N G G U I D E L I N E S
 SECTION VII – Appendices
APPENDIX J  BASIC ASC X12 RULES

Figure J-2 explains the components of a segment Data Element Separator – The character
4. 
and an element. selected by the sender which precedes every
data element, whether the data element is used
SEGMENT DIAGRAM KEY or not. The data element separator must be
different from the segment terminator and, once
Figure J-2 illustrates how a data segment provides
selected, must not appear in a data element
references to codes and terms used in the ASC
value.
X12 standards. (Note that the actual interchange
of information does not include all the reference
5. Data Element Name – The name of the data
characters shown in the diagram. Only the data
element.
segment identifier characters, the values for each
data element, the data element separator, and the
Segment Terminator – The character selected
6. 
data segment terminator characters are actually
by sender to end each data segment. The
transmitted.)
segment terminator must be different from
the data element separator and, once selected,
1 2 3 4 5 6 must not appear in a data element value. (For
CCD and PPD payments with addenda, this will
always be a backslash.)
DTM01 374 DMT02 373 DTM03 337 DTM04 624 DTM05 624

7. 
Data Element Requirement Designator –
Defines the circumstances under which a data
Date/Time
DTM *
Qualifier
* Date * Time * Time Code * Century * N/L
element must be present or not present in a
particular data segment. The Data Element
Requirement Designators are: mandatory,
M ID  3/3 X  DT  6/6 X  TM  4/6 O ID 2/2 O N 2/2 optional, or relational.

Data Element Type – Describes the characters

8. 
7 8 9 that may be used.
FIGURE J-2
N = Numeric
R = Decimal
Segment Identifier – A unique combination of
1.  ID = Identifier
two or three letters or digits used to identify the
AN = String
segment.
DT = Date
Data Element Reference Designator – The
2.  TM = Time
structured code assigned to a data element to
indicate the segment in which it is used and Data Element Length – The minimum and
9. 
its sequential position within that segment. maximum length of the data element. The
This code is made up of the Segment Identifier length of the data element value is the number
followed by a two digit sequence number. of character positions used except as noted for
numeric and decimal elements.
Data Element Reference Number – A unique
3. 
reference number used to locate the data The format for ACH addenda records was developed
element definition and specifications in the to provide up to 80 characters of payment-related
Data Element Dictionary (standard where the information. For CCD and PPD entries, there is a
contents of all data elements are defined). limit of one addenda record per transaction.

2 0 1 3 O P E R AT I N G G U I D E L I N E S OG183