2015 nacha compliance summary guide · 2018-12-12 · and guidelines. nacha identifies and...

[1]

2015

NACHA COMPLIANCE

SUMMARY GUIDE

Note: This compliance summary guide is provided by Jack Henry & Associates solely as a convenience to its

ProfitStars™ Enterprise Payment Solutions customers and is not intended to provide legal advice or

interpretation regarding the requirements of the NACHA Rules or any other legal aspects of processing ACH

transactions. The user of this Guide should become familiar with the provisions and requirements of the

current NACHA Rules and should seek competent business advice and legal counsel and exercise his or her own

judgments in applying the NACHA Rules and laws and regulations relating to the ACH processing activities

undertaken by his or her organization. While Jack Henry & Associates has exercised care in accurately

summarizing the contents of selected current NACHA Rules in this Guide, it cannot guarantee that its summary

of the NACHA Rules in this Guide provides a comprehensive treatment of the NACHA Rules and laws or

regulations applicable to ACH processing or that this Guide is completely up to date with the latest updates to

the NACHA Rules that may be issued by NACHA from time to time.

NOTE: Any reliance upon the contents of this Guide will be at the user’s sole risk.

© Copyright 1999-2015 Jack Henry & Associates, Inc. All rights reserved. Information in this document is subject to change

without notice.

[2]

Table of Contents Overview ............................................................................................................................................................................... 4

2015 Revisions to NACHA Operating Rules ......................................................................................................................... 5

ACH Network Risk and Enforcement ............................................................................................................................... 5

Return Rate Levels (Effective September 18, 2015) .................................................................................................... 5

Reinitiation of Entries (Effective September 18, 2015) ................................................................................................ 5

Third-Party Sender Issues (Effective date January 1, 2015) ........................................................................................ 5

NACHA’s Enforcement Authority (Effective date January 1, 2015) .......................................................................... 6

Improving ACH Network Quality – Unauthorized Entry Fee ........................................................................................... 6

Unauthorized Entry Fee (Effective October 3, 2016) .................................................................................................. 6

Minor Rule Topics ............................................................................................................................................................... 7

Point of Sale (POS) Entries (Effective January 1, 2015) ............................................................................................... 7

Return Entry Formatting Requirements (Effective January 1, 2015) .......................................................................... 7

Entry Detail Record for Returns – Clarification Regarding POP Entries (Effective January 1, 2015) ....................... 7

Clarification of RDFI’s Obligation to Recredit Receiver (Effective January 1. 2015) ............................................... 7

Clarification of Prenotification Entries and Addenda Records (Effective January 1. 2015) ................................... 7

Clarification of Audit Requirements for Participating DFI’s Reporting Network Administration Fees (Effective

August 22, 2014 – applicable for 2014 audit) .............................................................................................................. 7

Clarification on Company Identification for P2P WEB Credit Entries (Effective January 1. 2015) .......................... 7

What is ACH? ........................................................................................................................................................................ 8

What is Authorization? .......................................................................................................................................................... 9

What is an ACH Return? ..................................................................................................................................................... 10

What happens when an entry returns? .................................................................................................................................. 10

Why are entries returned? .................................................................................................................................................... 10

What is a Notification of Change (NOC)? ....................................................................................................................... 11

What happens when a NOC is received? ................................................................................................................................. 11

Why a Notification of Change? .............................................................................................................................................. 11

What is ARC? ....................................................................................................................................................................... 12

ARC Compliance Considerations ................................................................................................................................. 13

ARC Eligibility Requirements ........................................................................................................................................... 14

What is BOC? ...................................................................................................................................................................... 16

BOC Compliance Considerations ................................................................................................................................. 17

BOC Eligibility Requirements ................................................................................................................................................. 18

What is CCD? ...................................................................................................................................................................... 20

CCD Compliance Considerations ................................................................................................................................. 20

What is POP? ....................................................................................................................................................................... 21

[3]

POP Compliance Considerations .................................................................................................................................. 22

POP Receipt Requirements ............................................................................................................................................ 23

POP Eligibility Requirements ........................................................................................................................................... 25

What is PPD? ....................................................................................................................................................................... 27

Sample PPD Authorization Language ........................................................................................................................... 28

What is RCK? ....................................................................................................................................................................... 29

RCK Compliance Considerations .................................................................................................................................. 30

RCK Eligibility Requirements ........................................................................................................................................... 31

What is TEL? ......................................................................................................................................................................... 34

TEL Compliance Considerations .................................................................................................................................... 35

What is WEB? ....................................................................................................................................................................... 38

WEB Compliance Considerations .................................................................................................................................. 40

Sample WEB Authorization Language .......................................................................................................................... 42

Risk Management Requirements ........................................................................................................................................... 43

Common Return Reason Codes ....................................................................................................................................... 44

Common Change Codes .................................................................................................................................................. 46

[4]

Overview

The ProfitStars® Division of Jack Henry & Associates (“ProfitStars”) enables your organization to process

transactions using the ProfitStars Enterprise Payment Solution system through the Automated Clearing

House (ACH) Network. NACHA was formed in 1974 to coordinate the ACH Network, which is governed

by operating rules and guidelines, which are developed by the actual users of the system, and is

administered through a series of agreements among financial institutions, customers, trading partners,

and ACH Operators.

While the NACHA Operating Rules is the primary document addressing the rules and regulations for the

commercial ACH Network, Federal Government ACH payments are controlled by the provisions of Title

31 Code of Federal Regulations Part 210 (31 C.F.R. Part 210). The Financial Management Service (FMS)

of the U.S. Department of the Treasury is the agency responsible for establishing Federal Government

ACH policy. Other laws that have a direct bearing on ACH operations are the Uniform Commercial Code

Article 4, which governs check transactions, and Article 4A, and the Electronic Funds Transfer Act as

implemented by Regulation E.

The ProfitStars Enterprise Payment Solution system is designed to operate in full compliance with the

regulations governing the ACH Network. However, many of the requirements must be carried out by

the Originator. It is ultimately the responsibility of the Originator to fully comply with all of the

regulations governing the ACH Network, including the NACHA Operating Rules. (Please refer to your

signed ProfitStars Agreement.) We strongly recommend that you keep a current copy of the NACHA

Operating Rules on hand. (Copies are available through www.nacha.org)

The ACH Network supports a variety of payment types, each governed by a unique set of operating rules

and guidelines. NACHA identifies and recognizes each payment type by a specific three-digit code,

known as a Standard Entry Class (SEC) Code. Included in this guide are summaries of the ACH payment

types supported by ProfitStars.

This compliance summary is provided as a convenience and is not intended to provide legal advice. If you

have any questions about the information presented in this guide, please refer to the NACHA Operating

Rules or contact ProfitStars Partner Support team at 800-299-4467.

http://www.nacha.org/

[5]

2015 Revisions to NACHA Operating Rules

ACH Network Risk and Enforcement

Return Rate Levels (Effective September 18, 2015)

This rule addresses concerns related to unauthorized transactions by reducing the current return rate

threshold for unauthorized debit Entries (Return Reason Codes R05, R07, R10, R29 and R51) from 1.0 to

0.5 percent.

ODFI’s have the same obligations for monitoring return rates of their Originators and/or Third-Party

Senders and is subject to the same enforcement as currently established in the Rules.

Establishing Administrative Debit and Overall Debit Returns

This rule establishes two new return rate levels in the Rules:

A return rate level of 3.0 percent will apply to debit entries returned

o R02 – Account Closed

o R03 – No Account/Unable to Locate Account

o R04 – Invalid Account Number Structure

A return rate level of 15.0 percent will apply to all debit entries (excluding RCD) that are

returned for any reason.

The Rule establishes an inquiry process, separate from a Rules enforcement proceeding, as a

starting point for evaluating activity of Originators and Third-Party Senders that reach the

new administrative return and overall debit return rate levels.

Reinitiation of Entries (Effective September 18, 2015)

Subsection 2.12.4 of the Rules implicitly prohibits the reinitiation of Entries outside of the express

limited circumstances permitted by the rules.

Effective September 18, 2015 this Rule makes this prohibition explicit and adds a specific prohibition

against reinitiating a transaction that was returned as unauthorized.

Also, the Rule expressly states that a debit Entry is not considered a reinitiation if the Originator obtains

a new authorization for the debit Entry after the receipt of the Return.

Third-Party Sender Issues (Effective date January 1, 2015)

[6]

Subsection 2.2.3 of the Rules includes a direct obligation on Third-Party Senders to monitor, assess and

enforce limitations on their customer’s origination and return activities in the same manner the Rules

require of ODFI’s.

In addition the Rule is updated with certain reporting requirements in order to streamline oversight of

Third-Party Service Providers and Third-Party Senders. See subsection 1.2.2 and Appendix Eight of the

Rules regarding Rules compliance audit requirements.

NACHA’s Enforcement Authority (Effective date January 1, 2015)

In Subpart 10.2.2 of Appendix Ten of the Rules, NACHA has authority to initiation a Rules enforcement

proceeding in three specific circumstances. In order to provide NACHA the tools to act promptly, the

Rule includes the express authority for NACHA to bring an enforcement action based on the origination

of unauthorized entries. The Rule requires the ACH Rules Enforcement Panel to validate the materiality

of this type of enforcement case before NACHA can initiate any such proceeding.

Improving ACH Network Quality – Unauthorized Entry Fee

Unauthorized Entry Fee (Effective October 3, 2016)

The Rule will require an ODFI to pay a fee to an RDFI for ACH debit returns due to:

R05 – Unauthorized Debit to Consumer Account Using Corporate SEC Code

R07 – Authorization Revoked by Customer

R10 – Customer Advised Not Authorized, Notice Not Provided, Improper Source Document,

or Amount of Entry Not Accurately Obtained from Source Document

R29 –Corporate Customer Advised Not Authorized

R51 – Item is Ineligible, Notice Not Provided, Signature Not Genuine, Item Altered, or

Amount of Entry Not Accurately Obtained from Item

Methodology for Setting Fees

The Rule defines a methodology by which NACHA staff will sent and review every three years the

amount of the Unauthorized Entry Fee. NACHA estimates the fee will range from $3.50 - $5.50 based on

current collection of data.

Collection and Disbursement of Fees

NACHA and the two ACH Operators will arrange for a system to collect and distribute the fees.

[7]

Minor Rule Topics

Point of Sale (POS) Entries (Effective January 1, 2015)

The Rule re-aligns the general rule for POS Entries with the definition for POS Entries in Article Eight

Return Entry Formatting Requirements (Effective January 1, 2015)

The Rule revises the formatting requirements for certain Return Fee Entries to align with the formatting

requirements specific to the underlying transaction to which the return fee relates.

Entry Detail Record for Returns – Clarification Regarding POP Entries (Effective January

1, 2015)

This Rule adds a footnote to the Entry Detail Record for Return Entries to clarify the specific use of

positions 40-54 with respect to the return of a POP Entry.

Clarification of RDFI’s Obligation to Recredit Receiver (Effective January 1. 2015)

This Rule clarifies that an RDFI’s obligation to Recredit a Receiver for an unauthorized or improper debit

Entry is generally limited to Consumer Accounts, with certain exceptions for check conversion and

international transactions.

Clarification of Prenotification Entries and Addenda Records (Effective January 1. 2015)

This Rule revises the NAHCA Operating Rules to clarify that, with the exception of IAT Entries, a

Prenotification Entry is not required to include addenda records that are associated with a subsequent

live Entry.

Clarification of Audit Requirements for Participating DFI’s Reporting Network

Administration Fees (Effective August 22, 2014 – applicable for 2014 audit)

This Rule revised the annual rules compliance audit provisions for all Participating SFI’s to clarify that a

Participating DFI’s obligation to verify that it has paid annual and per-Entry fees to NACHA is applicable

only when that Participating DFI exchanges Entries through a means other than through an ACH

Operator (i.e. a direct send between the Participating SFI and another, non-affiliated Participating DFI).

Clarification on Company Identification for P2P WEB Credit Entries (Effective January 1.

2015)

This Rule adds language to the Company Identification field description to clarify content requirements

for Person-to-Person (P2P WEB credit Entries.

[8]

What is ACH? The Automated Clearing House (ACH) Network

The ACH Network is a highly reliable and efficient nationwide batch-oriented electronic funds transfer

system governed by the NACHA Operating Rules, which provide for the interbank clearing of electronic

payments for participating depository financial institutions. The Federal Reserve Bank and Electronic

Payments Network are the two ACH Operators that serve as the central clearing facilities through which

financial institutions transmit and receive ACH entries.

Originator

Any individual, corporation or other entity that initiates entries into the ACH Network

Originating Depository Financial Institution (ODFI)

A participating financial institution that originates ACH entries at the request of and by (ODFI)

agreement with its customers. ODFI’s must abide by the provisions of the NACHA Operating Rules and

Guidelines

Third Party Service Provider

A Third Party Service Provider handles any aspect of the ACH process on behalf of an originator, ODFI, or

RDFI. NOTE: ProfitStars operates in this capacity.

Receiving Depository Financial Institution (RDFI)

Any financial institution qualified to receive ACH entries that agrees to abide by the NACHA Operating

Rules and Guidelines

Receiver

Any individual, corporation or other entity who has authorized an Originator to initiate a credit or debit

entry to a transaction account held at an RDFI

[9]

What is Authorization? Authorization is permission.

Originators must obtain authorization from a receiver to effect entries to the receivers account. The

manner in which authorization can obtained differs by Standard Entry Class (SEC) codes and originators

should refer to the rules for the types of entries they will originate to determine the specifics for each

entry type.

General Authorization Guidelines

Consumer Accounts

A credit entry to a Consumer Account does not require written authorization when both the Originator

and the Receiver are natural persons.

Debit entries to a Consumer Account must be in writing and signed or similarly authenticated (i.e. e-

sign) except as the rules provide in the authorization requirements specific to each SEC code.

An Authorizations must:

be readily identifiable as an authorization

have clear and readily understandable terms

provide that the Receiver may revoke the authorization in the manner outlined in the authorization

Non-Consumer Accounts (Business Accounts)

Any entry effected to a Non-consumer account must be originated as a Corporate Credit or Debit (CCD).

The NACHA Operating Rules do not require the CCD authorization to be in a specific form. The Rules

require that the Originator and Receiver have an agreement that binds the Receiver to The Rules.

NOTE: Effective September 19, 2014 Originators of CCD entries must be able to provide accurate record evidencing the Receiver’s authorization upon request from the ODFI/ProfitStars.

[10]

What is an ACH Return?

An ACH Return is an entry that has been rejected by the Receiving Depository Financial Institution (RDFI)

because it cannot be processed.

What happens when an entry returns?

When the ODFI/ProfitStars receives a return entry that entry is posted to your Merchant Settlement

Account. If the return entry is a debit your Merchant Settlement Account will be debited. Conversely, if

the return entry is a credit your Merchant Settlement Account will be credited.

Why are entries returned?

There are various reasons that an RDFI may return an entry. Each Return Entry is accompanied by a

Return Reason Code. Please see a list of the most common return reason codes on Page 37-38. For a

complete list of Return Reason Codes please refer to Appendix Four of the NACHA Operating Rules and

Guidelines.

[11]

What is a Notification of Change (NOC)?

Notification to a merchant from a receiver's bank indicating that bank account information provided

with a specific transaction was incorrect and provides correct information. (Also known as a COR Entry)

What happens when a NOC is received?

When the ODFI/ProfitStars receives a Notification of Change (COR Entry) the information contained in

the Entry is provided to the Merchant. The Merchant (Originator) is required to make the changes

specified in the NOC within 6 Banking Days of receipt of the information or prior to initiating another

Entry to the Receiver’s account, whichever is later.

Why a Notification of Change?

There are various reasons that an RDFI may initiate a NOC. Each NOC is accompanied by a Change Code.

Please see a list of common Change Codes on Page 40. For a complete list of Change Codes please refer

to Appendix Five of the NACHA Operating Rules and Guidelines.

[12]

What is ARC?

The Standard Entry Class code for Accounts Receivable Entries is ARC. ARC is a single-entry ACH debit

that takes place when an Originator receives and converts a check payment that is sent via mail or

deposited into a drop box. When the paper check is converted, it is then referred to as a “source

document”.

NOTE: Effective March 16, 2012 the Rules are amended to permit the use of ARC for the conversion of checks tendered in person for the payment of a bill at a manned location.

What types of businesses benefit from offering ARC?

Any company that receives check remittances through the mail or in a drop box should evaluate the

benefits of ARC. A wide variety of industries take advantage of ARC, such as credit card companies,

utility companies and mortgage companies and other billers. Property management companies,

lenders, health care providers, government agencies, educational institutions and not-for-profit

organizations also enjoy the following benefits of using ARC:

Cost-savings created by processing paper checks as ACH transactions;

Reduced time-frame for processing payments;

Receive earlier notification of returned items;

Reduction in errors resulting from manual processing.

For the most recent NACHA published statistics regarding ARC please visit: ACH Network Statistics

Originators of ARC transactions are ultimately responsible to comply in full with applicable regulations,

including Regulation E and the NACHA Operating Rules. For additional compliance information, please

refer to a current version of the NACHA Operating Rules.

https://www.nacha.org/ACHntwkstats

[13]

ARC Compliance Considerations

As established by the NACHA Operating Rules, there are a number of compliance requirements for

Originators that accept ARC transactions, including advance notice of the intent to convert the check,

electronic capture of payment information from the MICR line and retention of a copy of the source

document. Additionally, there are eligibility requirements that checks must meet for conversion to ARC.

Compliance Checklist for ARC Transactions

Authorization Requirements

The Originator provides notice to the customer of the company’s intent to convert the check, typically on an invoice or billing statement; for checks deposited in a drop box, notice should be clearly displayed on signage;

Notice must clearly and conspicuously state that receipt of the check will authorize an ACH debit;

NOTE: Effective March 18, 2011 the requirement that Originators of ARC entries have procedures in place to allow Receivers to opt out of check conversion is optional.

Sample ARC Authorization Language

Note: The sample authorization language is provided for illustrative purposes only. Originators should consult with their

legal counsel. ProfitStars requires Originators to provide a copy of the current authorization upon request.

When you provide a check as payment, you authorize us to either use information from your

check to make a one-time electronic fund transfer from your account or to process the payment as a

check.

Alternative Reg-E safe harbor language:

When you provide a check as payment, you authorize us to use information from your check to

make a one-time electronic fund transfer from your account. In certain circumstances, such as for

technical or processing reasons, we may process your payment as a check transaction.

[14]

ARC Eligibility Requirements An Originator may accept a check as a source document for ARC if it meets the following criteria:

Must contain a pre-printed check serial number;

Must be in an amount of $25,000 or less;

Must be completed and signed by Receiver;

Must have a Routing Number, Account Number, and check serial number encoded in magnetic ink;

Presentment via U.S. mail or drop box;

Originator must provide notice to Receiver;

Originator must use a reading device to capture the MICR line from the check.

Ineligible items include:

1. Checks or share drafts that contain an Auxiliary On-Us Field in the MICR line; 2. Check or share draft payable to person other than Originator; 3. Check or share draft that does not contain signature of Receiver; 4. Check or share draft that accesses credit card account, Home Equity Line, or other form of

credit; 5. Check drawn on investment company as defined in the Investment Company Act of 1940; 6. Obligations of an FI (travelers checks, money orders etc.); 7. Checks drawn on the Treasury of the U.S., a FRB or Federal Home Loan Bank; 8. Checks drawn on a state or local government that is not payable through or at a Participant DFI; 9. Checks or share drafts payable in a medium other than United States currency.

Capturing Payment Information from the MICR line

NACHA sets forth specific guidelines for capturing payment information from the source document:

Originators must use an electronic check reading device to capture MICR information, such as the account number, routing number and serial number;

Originators are prohibited from key entering MICR information from the check, except for correcting errors from the reader device;

Originators may key enter the transaction amount.

Retention of Source Document or Copy

The NACHA Rules do not specify a destruction requirement timeframe. All banking information must be

securely stored in a commercially reasonable manner. A copy of the front of the source document must

be stored and available upon request for two years from the Settlement Date of the transaction. If

requested, the Originator’s bank has 10 banking days to provide a copy of the source document.

[15]

Collection of Fees

ARC entries must be originated so that the amount of the entry, the routing number, the account

number, and the check serial number accurately reflect the source document. No fees of any type may

be added to the amount of the source document when it is transmitted as an ARC entry.

An Originator desiring to use the ACH Network to collect a service fee from a Receiver must originate a

separate entry using the appropriate Standard Entry Class Code and must follow all rules governing the

specific transaction used, including having first obtained the Receiver’s authorization for such an entry in

the manner specified by the NACHA Operating Rules.

Originators need to be aware that the requirements of the NACHA Operating Rules are in addition to

any requirements defined by applicable state law governing service fees. Originators are responsible for

determining what the applicable state laws are, if any, for each of their check-accepting locations that

intend to, or may, use the ACH Network for the collection of service fees.

Source: NACHA Operating Rules & Guidelines 2014 – Chapter 37 – OG126.

[16]

What is BOC? The Standard Entry Class code for Back Office Conversion is BOC. Organizations that accept checks at

the point of sale or manned bill payment locations can convert paper checks to an ACH debit in a

location away from the point of sale, such as a back office. BOC entries are single-entry debits and may

only be used for non-recurring, in-person payments.

What types of businesses benefit from offering BOC?

BOC can help companies of all sizes, whether they accept a handful or a significant number of checks. A

wide range of industries enjoy a variety of advantages by utilizing BOC. Some examples include multi-

lane retailers like grocery stores, health care providers and pharmacies, utility companies and not-for-

profit organizations. Other companies that benefit by using BOC include in-home service providers,

professional service providers like attorneys, retail service businesses and quick service/delivery

restaurants.

Some of the notable BOC benefits include:


Reduced time-frame for processing payments;

Earlier notification of returned items;

Reduction of errors resulting from manual processing;

The ability to convert checks accepted at the point of sale with minimal impact upon the customer experience;

Because the checks are converted away from the point of sale, the checkout process flows normally.

For the most recent NACHA published statistics regarding BOC please visit: ACH Network Statistics

Originators of BOC transactions are ultimately responsible to comply in full with applicable regulations, including

Regulation E and the NACHA Operating Rules. For additional compliance information, please refer to a current

version of the NACHA Operating Rules.


[17]

BOC Compliance Considerations


Originators that accept BOC transactions, including advance notice of the intent to convert the check,

electronic capture of payment information from the MICR line and retention of a copy of the source

document. Additionally, there are eligibility requirements that checks must meet for conversion to BOC.

Compliance Checklist for BOC Transactions

Authentication Requirement

Originators are required to verify the identity of the consumer at the point of sale.


The Originator provides notice to the customer of the company’s intent to convert the check on signage at the point of sale that is posted in a prominent and conspicuous manner;

A copy of the notice must be provided to the customer at the time of the transaction;

Both notices must include a working customer service telephone number for customer inquiries, which is answered during normal business hours.

NOTE: Effective March 18, 2011 the requirement that Originators of BOC entries have procedures in place to allow Receivers to opt out of check conversion is optional.

[18]

Sample BOC Authorization Language


legal counsel. ProfitStars requires Originators to provide a copy of the current authorization upon request..



check transaction. For inquiries please call <customer service phone number>.

BOC Eligibility Requirements

An Originator may accept a check as a source document for BOC if it meets the following criteria:





Presentment at point-of-purchase or manned bill payment location for conversion during back-office processing;

Originator must provide notice to Receiver;

Originator must use a reading device to capture the MICR line from the check.


1. Checks or share drafts that contain an Auxiliary On-Us Field in the MICR line; 2. Check or share draft payable to person other than Originator; 3. Check or share draft that does not contain signature of Receiver; 4. Check or share draft that accesses credit card account, Home Equity Line, or other form of


[19]





Originators may key enter the transaction amount.

Retention of Source Document or Copy

The NACHA Rules do not specify a destruction requirement timeframe. All banking information must be

securely stored in a commercially reasonable manner. A copy of the front of the source document must

be stored and available upon request for two years from the Settlement Date of the transaction. If

requested, the Originator’s bank has 10 banking days to provide a copy of the source document.

Collection of Fees

BOC entries must be originated so that the amount of the entry, the routing number, the account

number, and the check serial number accurately reflect the source document. No fees of any type may

be added to the amount of the source document when it is transmitted as a BOC entry.


separate entry using the appropriate Standard Entry Class Code and must follow all rules governing the

specific transaction used, including having first obtained the Receiver’s authorization for such an entry in

the manner specified by the NACHA Operating Rules.

Originators need to be aware that the requirements of the NACHA Operating Rules are in addition to

any requirements defined by applicable state law governing service fees. Originators are responsible for

determining what the applicable state laws are, if any, for each of their check-accepting locations that

intend to, or may, use the ACH Network for the collection of service fees.


[20]

What is CCD? The Standard Entry Class code for corporate ACH entries is CCD. The CCD code applies to both single-

entry and recurring payments. Originators are required to have an agreement with the Receiver that

binds them to the NACHA Rules.

CCD Compliance Considerations

NOTE: Effective September 19, 2014 Originators of CCD entries must be able to provide accurate record evidencing the Receiver’s authorization upon request from the ODFI/ProfitStars.

What types of businesses benefit from offering CCD?

Almost any type of business can use CCD entries. Some of the commonly used applications for CCD

credits include paying monthly bills or taxes, funding branches, franchises or agents, funding employee

benefit accounts or charitable donations.

Benefits of using CCD for credits include:

Reduced cost per transaction versus check payments;

Eliminates the costs of replacing lost checks;

Reduced administrative costs, including labor to process checks, stamps, check stock.

Examples of CCD debits include consolidation of funds from branches or locations and collecting

corporate receivables.

Benefits of CCD debits include:


Reduced administrative burden of accounts payable;

Predictive cash flow;

No waiting for checks to clear.

For the most recent NACHA published statistics regarding CCD please visit: ACH Network Statistics

Originators of CCD transactions are ultimately responsible to comply in full with applicable regulations, including

the NACHA Operating Rules. For additional compliance information, please refer to a current version of the NACHA

Operating Rules:



[21]

What is POP? The Standard Entry Class code for Point-of-Purchase Check Conversion is POP. Organizations that accept

checks at the point of sale or manned bill payment locations can convert paper checks to an ACH debit

in a location. POP entries are single-entry debits and may only be used for non-recurring, in-person

payments. The consumer signs an authorization for conversion, and receives their voided check back

along with a document that provides information about the transaction.

What types of businesses benefit from offering POP?

POP can help companies of all sizes, whether they accept a handful or a significant number of checks. A

wide range of industries enjoy a variety of advantages by utilizing POP; for example, multi-lane retailers

like grocery stores, pharmacies, utility companies and not-for-profit organizations. Other companies

that benefit by using POP include automotive companies and retail service businesses, such as dry

cleaners and mail services stores.

Some of the notable POP benefits include:


Reduction of the time-frame for processing payments;


Reduction of errors resulting from manual processing.

For the most recent NACHA published statistics regarding BOC please visit: ACH Network Statistics

Originators of POP transactions are ultimately responsible to comply in full with applicable regulations, including




[22]

POP Compliance Considerations


Originators that accept POP transactions, including advance notice of the intent to convert the check,

providing the customer with a copy of the authorization notice and a receipt, and electronic capture of

payment information from the MICR line. The Originator must mark the check as “void” and return to

the customer. Additionally, there are eligibility requirements that checks must meet for conversion to

POP.

Compliance Checklist for POP Transactions

Although the NACHA Operating Rules do not prescribe specific authorization language for the point-of-

purchase application, the authorization must conform to the requirements of the NACHA Operating

Rules, which require that the authorization:


Originators are required to verify the identity of the consumer at the point of sale.


The Originator provides notice to the customer of the company’s intent to convert the check and must be readily identifiable as an ACH debit authorization on signage at the point of sale that is posted in a prominent and conspicuous manner;

A copy of the notice must be provided to the customer;

Originators must offer customers an opt-out method.

[23]

POP Receipt Requirements

In addition to the voided paper check, the Originator must also hand the consumer a document

containing specific information. The following information may be included on the same document as

the customer’s receipt.

REQUIRED OPTIONAL

Originator Name Merchant Address

Originator Phone Number Merchant Identification Number

Date of Transaction Receiver’s FI Routing Number

Transaction Amount Receiver’s TRUNCATED account number

Check Serial Number Receiver’s TRUNCATED identification number

Merchant Number (or other unique number that identifies the location of the transaction)

Transaction reference number

Terminal City

Terminal State

NOTE: The complete account number cannot be placed on the customer’s takeaway receipt or document

[24]

Sample POP Authorization Language



Signage Language:



check transaction.

Customer Authorization/Take-away Copy Language:

[Date]

[Merchant Name and Number]

[Street Address]

[City, State]

I authorize [Merchant] to convert my check and electronically debit my account for the sale

amount. For customer service inquiries, please call [phone number].

Sale Amount: [$] Check Number: [#]

________________________________

Customer Signature

[25]

POP Eligibility Requirements An Originator may accept a check as a source document for POP if it meets the following criteria:



Originator must use a reading device to capture the MICR line from the check;


Presentment at point-of-purchase or manned bill payment location;

Originator must provide notice to Receiver and copy of notice or similar language to Receiver at time of transaction and a written authorization from the Receiver;

Source document is voided and returned to Receiver;

Source document has not been used for a prior POP entry. Ineligible items include:

1. Checks or share drafts that contain an Auxiliary On-Us Field in the MICR line; 2. Check or share draft payable to person other than Originator; 3. Check or share draft that accesses credit card account, Home Equity Line, or other form of






Originators may key enter the transaction amount, along with any relevant customer information, such as address, phone number, driver’s license number, etc.;

The source document must be voided by the Originator and returned to the check writer at the time of the transaction.

[26]

Collection of Fees

Originators need to be aware that ACH notice and authorization requirements are in addition to any

requirements required by applicable state law governing returned-check service fees. Originators are

responsible for determining what the applicable state laws are, if any, for each of their check-accepting

locations that intend to, or may, use the POP application.

In addition, the authorization for the conversion of the check does not include authorization for any

returned-check fees that may become necessary to collect the check unless the authorization specifically

includes appropriate language covering such fees.


[27]

What is PPD? A Standard Entry Class code frequently used for consumer ACH entries is PPD. The PPD code applies to

both single-entry and recurring payments. A customer provides a written, signed or similarly

authenticated authorization for either a credit or debit transaction to their account. PPD entries can

either be single or recurring transactions. Standard PPD authorizations can be used for recurring bills

where the amount may vary.

What types of businesses benefit from offering PPD?

Almost any type of business can use PPD entries for transactions to a consumer account. Some of the

commonly used applications for PPD credits include direct deposit of payroll, Social Security payments,

payment for employee commissions or expense reimbursement and annuity payments.

Benefits of using PPD for credits include:

Reduced cost per transaction versus the cost of issuing a check;

Eliminates the cost of replacing lost checks;

Guaranteed payment date/time to employees;

Reduces the administrative burden of processing payments.

Examples of PPD debits include mortgage, loan and insurance payments, payments for credit card and

utility bills, charitable donations and recurring payments for health club memberships and subscriptions.

Benefits of PPD debits for companies include:

Eliminate check-handling procedures (i.e. opening mail, recording checks, trips to bank to make deposits, etc.);

Faster settlement;

Earlier notification of returned items.

For the most recent NACHA published statistics regarding PPD please visit: ACH Network Statistics

Originators of PPD transactions are ultimately responsible to comply in full with applicable regulations, including

the NACHA Operating Rules. For additional compliance information, please refer to a current version of the NACHA

Operating Rules.



[28]

Sample PPD Authorization Language



Sample PPD Authorization Language - Credits

Sample PPD Authorization Language - Debits

[29]

What is RCK? The Standard Entry Class code for Re-presented Check Entries is RCK. RCK entries are single-entry debits

to a consumer account use to re-present a paper check after the item has been returned unpaid.

Customers are required to sign an authorization and must receive a copy of the authorization language.

What types of businesses benefit from offering RCK?

RCK provides Originators with a more efficient method, compared to traditional NSF check methods.

RCK can help companies of all sizes, whether they accept a handful or a significant number of checks. A

wide range of industries enjoy processing efficiencies and decreased costs by utilizing RCK; for example,

multi-lane retailers like grocery stores, pharmacies, convenience stores, utility companies and health

care providers. Other companies that benefit by using RCK include professional service providers such

as attorneys, in-home service providers, retail service businesses and quick service/delivery restaurants.

Some of the notable RCK benefits include:

Cost-savings created by re-presenting paper checks as ACH transactions;

Reduction of the time-frame for processing payments, with faster access to collected funds;

Increased likelihood of collecting funds, due to the ability to target a specific re-presentment date;


Reduction of errors resulting from manual processing;

RCK allows an additional electronic presentment.

For the most recent NACHA published statistics regarding RCK please visit: ACH Network Statistics

Originators of RCK transactions are ultimately responsible to comply in full with applicable regulations, including




[30]

RCK Compliance Considerations


Originators that initiate RCK transactions, including advance notice of the intent to re-present the check

electronically. Additionally, there are eligibility requirements that checks must meet for conversion to

RCK.

Compliance Checklist for RCK Transactions


The Originator provides notice to the customer of the company’s intent to re-present the check as an

electronic debit in a clear and conspicuous manner, such as signage at the point of sale or at a drop box.

For checks received in the mail, notice should be clearly displayed on an invoice or with a monthly billing

statement.

Sample RCK Authorization Language



If your check is returned for insufficient funds or is unpaid, your account will be electronically debited.

Choosing to use a check for payment is your acknowledgement and acceptance of the terms and

conditions of this policy.

[31]

RCK Eligibility Requirements

An Originator may accept a check as a source document for RCK if it meets the following criteria:



Consumer accounts only;



Originator must provide notice to Receiver of the terms for initiating an RCK entry prior to receiving the source document to which the RCK relates;

Source document is dated 180 days or less from the date of the RCK entry;


1. Checks or share drafts that contain an Auxiliary On-Us Field in the MICR line; 2. Check or share draft payable to person other than Originator; 3. Check or share draft does not contain signature of the Receiver; 4. Check or share draft that accesses credit card account, Home Equity Line, or other form of


Number of Presentments

Originators may transmit a RCK entry no more than twice after the return of a paper item; or no more

than once after the second return of a paper item. (i.e. 2 times as a check, 1 time as RCK)

Retention of Copy of Item

A copy of the front and back of the check must be stored and available upon request for seven years

from the Settlement Date of the transaction. If requested, the Originator’s bank has 10 banking days to

provide a copy of the source document. If the check has been finally paid, this must be indicated on the

copy.

[32]

Collection of Fees

An Originator may transmit an RCK entry for the face amount of the returned check only. No collection

or service fees of any type may be added to the amount of the item when it is transmitted as an ACH

entry.


separate debit entry using the appropriate Standard Entry Class Code and must follow all rules

governing the specific transaction used, including having first obtained the Receiver’s authorization for

such an entry in the manner specified by the NACHA Operating Rules. These requirements of the Rules

are in addition to any requirements defined by applicable state law governing the collection of service

fees. Originators are responsible for determining what the applicable state laws are, if any, for each of

their check-accepting locations that intend to, or may, use the ACH Network for the collection of service

fees.

Some Originators may desire to place an authorization stamp on the check being used for payment of

goods or services in order to collect a returned check fee in the event that the check is returned for

insufficient or uncollected funds. In order for this practice to be compliant with the NACHA Operating

rules, the following requirements must be met:

An authorization placed on the check must be signed (not initialed). The signature must stand alone, i.e., the authorization language for the ACH debit entry must not be stamped in close proximity to the maker’s signature on the check such that it could appear that by signing the check, the check writer has also agreed to the authorization. The signature for authorization must clearly relate to the authorization language itself;

The authorization on the check must be readily identifiable as an ACH debit authorization and its terms must be clear and readily understandable (i.e., the print cannot be so small or smeared that a consumer would be unable to easily read the authorization and understand its terms);

The authorization on the check must contain information that explains how the consumer may revoke the authorization;

The Originator must provide the consumer with an electronic or had copy of the authorization;

The Originator must retain the original or a copy of the authorization for two years from the termination or revocation of the authorization.

Authorization language, if stamped on the back of the check, should be in the endorsement space

provided and not lower on the check. Before stamping the back of a check with anything other than an

endorsement, Originators must ensure that they understand and are in compliance with both the

NACHA Operating Rules and all regulations that govern the collection of checks.

[33]

Restrictive Endorsements

Any restrictive endorsement (such as “For Deposit Only”) placed on a check by the Originator is void or

ineffective when the item is presented as a RCK entry.


[34]

What is TEL? The Standard Entry Class code for Telephone-initiated ACH entries is TEL. TEL is used when an

Originator obtains authorization via the phone from a consumer to create an ACH debit. The TEL code

applies to single-entry payments and recurring payments. TEL transactions must be drawn on a

consumer account and be payable in U.S. currency. Additionally, TEL may only be used when:

A relationship already exists between the Originator and the consumer, OR

In the case where there is not an existing relationship, the consumer initiates the contact with the Originator

NOTE: Effective September 16, 2011, an amendment to the NACHA Operating Rules became effective that expands the scope of the TEL application to permit its use for recurring consumer transactions.

What types of businesses benefit from offering TEL?

A wide variety of industries benefit by offering TEL as a payment option to their customers. Billers such

as credit card companies, utility companies and mortgage companies enjoy widespread consumer

acceptance of TEL payments. Catalog retailers, government agencies, educational institutions, health

care providers and not-for-profit organizations also enjoy the following benefits of using TEL:

ACH offers reduced cost of processing transactions versus credit cards;

Increased customer loyalty by offering a convenient payment option;

By offering a payment option for those who don’t have or choose to use credit/debit cards, additional sales can be generated through an expanded customer base;

Enhanced customer satisfaction by creating a secure, convenient payment option for customers making last-minute payments.

For the most recent NACHA published statistics regarding TEL please visit: ACH Network Statistics

Originators of TEL transactions are ultimately responsible to comply in full with applicable regulations, including




[35]

TEL Compliance Considerations


Originators that accept TEL transactions. Each TEL authorization must contain confirmation of six

specific pieces of information, and the recorded version of the authorization or written follow-up notice

must also contain this information.

Compliance Checklist for TEL Transactions

Authentication Requirements

Originators are required to employ commercially reasonable authentication methods to verify the identity of the consumer. Originators need to establish a method to verify the consumer’s name, address and telephone number.

[36]

Authorization Requirements – Single Entry TEL

The Originator must obtain oral authorization from the Receiver prior to initiating a TEL debit to the Receiver’s account;

The authorization must be readily identifiable as an authorization and must have clear and readily understandable terms.

The following minimum information must be included as part of the authorization for a Single TEL Entry

o The amount of the recurring transactions or a reference to the method of determining the amount of the recurring transactions

o The timing, including the start date, number, and/or frequency of the electronic fund transfers, or other similar reference, to the Consumer’s account’;

o The Receiver’s name or identity; o The account to be debited; o The Originator’s customer service telephone number o The date of the Receiver’s oral authorization

For an authorization relating to recurring TEL Entries, the Originator must comply with the requirements of Regulation E for the authorization of preauthorized transfers, including the requirement to send a copy of the authorization to the Receiver.

The Receiver must unambiguously express consent to the terms of the authorization;

The Originator must either make an audio recording of the oral authorization, or provide the Receiver with written notice confirming the oral authorization prior to the Settlement Date of the Entry.

The Originator is required to store an original recording or a copy of the authorization for two years from the termination or revocation of the authorization, the original or a duplicate audio recording of the oral authorization, and evidence that a copy of the authorization was provided to the Receiver in compliance with Regulation E.

[37]

Authorization Requirements – Recurring Entry TEL

The Originator must obtain verbal authorization from the Receiver prior to initiating a TEL debit to the Receiver’s account;

The authorization must be readily identifiable as an authorization and must have clear and readily understandable terms.

The following minimum information must be included as part of the authorization for a Recurring TEL entry:

o The amount of the recurring transactions, or a reference to the method of determining the amounts of recurring transactions;

o The timing (including the start date), number, and/or frequency of the electronic fund transfers, or other similar reference, to the Consumer’s account;

o The Receiver’s name or identify; o The account to be debited; o A telephone number for Receiver inquiries that is answered during normal business

hours; o The date of the Receivers oral authorization.

For an authorization relating to recurring TEL Entries, the Originator must comply with the requirements

of Regulation e for the authorization of preauthorized transfers, including the requirement to send a

copy of the authorization to the Receiver.

Sample TEL Authorization Script:



[Name of Consumer], [Merchant Name] is requesting your authorization to electronically debit

your checking account, in the amount of [$ amount] on or about [date of ACH debit]. At any time prior

to processing, you may revoke this authorization by calling our customer service department at

[merchant phone number]. Do I have your authorization today [today’s date] to process this

transaction?

Risk Management Considerations

Originators are required to employ “commercially reasonable” procedures to verify the validity of the routing and transit number provided by the consumer; (ProfitStars includes routing and account number validation for all TEL transactions as a value-added service.)

Key entry responses for authorization purposes, via a system such as a voice response unit, do not qualify as an oral authorization under the NACHA Rules.


[38]

What is WEB? The Standard Entry Class code for Internet-initiated ACH entries is WEB. WEB is used when an

Originator obtains authorization via the Internet or a Wireless Network from a consumer to create an

ACH debit. The WEB code applies to both single-entry and recurring payments. WEB transactions must

be drawn on a consumer account and be payable in U.S. currency.

NOTE: Effective January 1, 2011 the definition of WEB Entries was expanded to include ACH debits authorized and/or initiated via wireless networks and requires that those payments utilize the WEB Standard Entry Class Code

ACH DATA SECURITY REQUIREMENT

The NACHA Operating Rules impose specific data security requirements for all ACH transactions that

involve the exchange or transmission of banking information (including, but not limited to, an entry,

entry data, a routing number, an account number, and a PIN or other identification symbol) via an

Unsecured Electronic Network. ACH participants must abide by these requirements.

ANNUAL DATA SECURITY AUDITS

The NACHA Operating Rules for WEB transactions require Originators to conduct an annual data security

audit to ensure that Receivers’ financial information is protected by security practices and procedures

that ensure that the financial information that the Originator obtains from Receivers is protected by

commercially reasonable security practices that include adequate levels of:

Physical security to protect against theft, tampering, or damage;

Administrative, technical, and physical access controls to protect against unauthorized access and use; and

Network security to ensure secure capture, transmission, storage, distribution and destruction of financial information.

NOTE: Originators of WEB transactions must provide proof of their Annual Data Security Audit to ProfitStars upon request.

[39]

What types of businesses benefit from offering WEB?

A wide variety of industries benefit by offering WEB as a payment option to their customers. Billers such

as credit card companies, utility companies and mortgage companies enjoy widespread consumer

acceptance of WEB payments. Online retailers, government agencies, educational institutions and not-

for-profit organizations also enjoy the following benefits of using WEB:

ACH offers reduced cost of processing transactions versus credit cards;

Increased customer loyalty by offering a convenient payment option;

Additional sales and an expand customer base, by offering a payment option for those who don’t have or choose to use credit/debit cards;

Enhanced customer satisfaction by creating a secure, convenient payment option for customers making last-minute payments.

For the most recent NACHA published statistics regarding WEB please visit: ACH Network Statistics

Originators of WEB transactions are ultimately responsible to comply in full with applicable regulations, including




[40]

WEB Compliance Considerations


Originators that accept WEB transactions. The unique nature of Internet creates risk considerations that

are addressed by the requirements. Additionally, the varying levels of risk must be managed

appropriately, based on the type of WEB transaction presented:

Single-entry transactions (a one-time transfer of funds between the Originator and an established customer, typically to pay a bill or make a donation);

“Spontaneous” transactions (a one-time online purchase by a customer without a previous relationship with the Originator);

Recurring payments (a transfer of funds set up to occur automatically at regular intervals by a known customer).

When NOT to use WEB Entries

WEB is not appropriate if the authorization is oral (example: authorization is given orally via a device over a Wireless Network);

WEB is not appropriate if the Receiver’s instructions for initiation of the debit entry are communicated to the Originator over the Internet via a wired network but the authorization has been given in some other manner (example: written authorization was obtained from the Receiver through the mail to debit his account for a bill payment service but he goes to the biller’s website to verify the amount of the bill each month, this transaction would constitute a PPD entry rather than a WEB entry)

WEB is not appropriate to initiate credit entries except for the reversing entry to correct a previous WEB debit entry;

WEB is not appropriate to initiate debit or credit entries for business transactions.

[41]

Compliance Checklist for WEB Transactions


Originators are required to employ commercially reasonable authentication methods to verify the identity of the Receiver;

The Originator must authenticate the Receiver before obtaining authorization.


The Originator must obtain authorization from the Receiver prior to initiating a WEB debit to the consumer’s account;

The authorization must be in writing that is “signed” or similarly authenticated by the Receiver;

The authorization is obtained in any manner permissible for other Standard Entry Class Codes, but the Receiver’s instructions for the initiation of the debit entry is communicated via a Wireless Network (other than by an oral communication;

The authorization must be readily identifiable as an ACH debit authorization;

The authorization must express its terms in a clear and readily understandable manner;

For recurring payments, the authorization language must specify a method for revocation of the authorization;

The Receiver should be encouraged to print and retain a copy of the authorization;

The Receiver must be able to read the authorization displayed on the computer screen;

The Originator must be able to provide the Receiver with a copy of the authorization if requested to do so;

Only the Receiver may authorize the WEB transaction, and not a Third-party service provider;

The Originator is required to store a copy of the authorization, and produce a copy upon request.

The following pieces of information should be included in the authorization:

Express authorization language (“I authorize Company A to debit my account”)

Amount of transaction o For a Single-Entry payment o For a recurring entry that is for the same amount each interval, or o For a range of payments

The effective date of the transaction

The Receiver’s account number

The Receiver’s financial institution routing number

Revocation language (recurring payments only)

[42]

Sample WEB Authorization Language Note: The sample authorization language is provided for illustrative purposes only. Originators should consult with their


Single Entry Debit:

The payment of [$ amount] will be electronically debited from your account.

I authorize [Merchant Name] to electronically debit the account listed above for the amount of

this purchase. If this item is dishonored or returned for any reason, I authorize an additional debit to the

account listed above for $25 or the maximum amount allowed by state law, whichever is greater. By

clicking on the button below, I agree to the terms of this agreement and authorize this purchase.

Please print this form before pressing the “I accept terms of this Agreement” button. Remember

to record this transaction in your check register. You will receive an email confirmation of this purchase.

Recurring Debits:

The first payment of [amount] will be electronically debited from your account. There will be an

addition [# of debits] [periodic recurrence, such as weekly, monthly, etc.] recurring payments on the

[numerical date, such as 15th] day of every [periodic occurrence] beginning on [date].

I authorize [Merchant Name] to electronically debit the account listed above for the amount of the

check. If this item or any subsequent recurring item is dishonored or returned for any reason, I authorize

an additional debit to the account listed above for $25 or the maximum amount allowed by state law,

whichever is greater. By clicking on the button below, I agree to the terms of this agreement and

authorize this purchase.

Please print this form before pressing the “I accept terms of this Agreement” button. Remember to

record these transactions in your check register. You will receive an email confirmation of this purchase.

To revoke this authorization, please contact [Merchant Name] customer service at [Merchant phone

number].

[43]

Risk Management Requirements

Originators are required to utilize “commercially reasonable” fraudulent detection system. (Examples of fraudulent transaction detection systems are systems that track transaction volume and velocity, payment history or purchase type, delivery information, etc.);

Originators are required to employ “commercially reasonable” procedures to verify the validity of the routing and transit number provided by the consumer; (ProfitStars includes routing and account number validation for all WEB transactions as a value-added service.)

A secure session utilizing a minimum level of security, equivalent to 128-bit RC4 encryption technology or greater, must be employed prior to the key-entry of the consumer’s banking information and through the transmission of the data to the Originator;

An annual data security audit must be conducted, including evaluation of the following components:

o Physical security to protect against theft, tampering or damage; o Personnel and access controls to protect against unauthorized access and use; o Network security to ensure secure capture, storage and distribution.


[44]

Common Return Reason Codes

CODE TITLE DESCRIPTION

R01 Insufficient Funds (NSF) The available and/or cash reserve balance is not sufficient to cover the dollar value of the debit Entry.

R02 Account Closed A previously active account has been closed by action of the customer of the RDFI.

R03 No Account/Unable to Locate Account

The account number structure is valid and it passes the Check digit validation, but the account number does not correspond to the individual identified in the Entry, or the account number designated is not an existing account.

R04 Invalided Account Number Structure

The account number structure is not valid.

R05 Unauthorized Debit to Consumer Account Using Corporate SEC Code

CCD or CTX debit Entry was transmitted to a Consumer Account of the Receiver and was not authorized by the Receiver.

R07 Authorization Revoked by Customer

The RDFI’s customer (Receiver) revoked the authorization previously provided to the Originator for this debit Entry.

R08 Payment Stopped The Receiver has placed a stop payment order on this debit Entry.

R09 Uncollected Funds A sufficient ledger balance exists to satisfy the dollar value of the transaction, but the available balance is below the dollar value of the debit Entry.

R10 Customer Advises Unauthorized, Improper, Ineligible, or part of an Incomplete Transaction

The RDFI has been notified by the Receiver that the Entry is unauthorized, improper, ineligible, or part of an Incomplete Transaction.

R12 Account Sold to Another DFI A financial institution received an Entry to an account that was sold to another financial institution.

R20 Non-Transaction Account ACH Entry to a non-Transaction Account.

R29 Corporate Customer Advises Not Authorized

The RDFI has been notified by the Receiver (non-consumer) that a specific Entry has not been authorized by the Receiver.

[45]

Common Return Reason Codes (continued)

CODE TITLE DESCRIPTION

R36 Return of Improper Credit Entry ACH credit Entries (with the exception of Reversing Entries) are not permitted for use with ARC, BOC, POP, RCK, TEL, WEB, and XCK. ACH credit Entries (with the exception of Reversing Entries) are not permitted for use with ARC, BOC, POP, RCK, TEL, and XCK*.

R37 Source Document Presented for Payment

The source document to which an ARC, BOC, or POP Entry relates has been presented for payment.

R38 Stop Payment on Source Document

The RDFI determines a stop payment order has been placed on the source document to which the ARC or BOC Entry relates.

R39 Improper Source Document/Source document Presented for Payment

The RDFI determines that: (1) the source document used for an ARC, BOC or POP Entry to its Receiver’s account is improper, or (2) an ARC, BOC or POP Entry and the source document to which the Entry relates have both been presented for payment and posted to the Receiver’s account.

R50 State Law Affecting RCK Acceptance

The RDFI is located in a state that has not adopted Revised Article 4 of the Uniform Commercial Code (1990 Official Text) and has not revised its customer agreements to allow for Electronic presentment OR The RDFI is located within a state the requires all canceled Checks to a specific type of account to be returned to the Receiver within the periodic statement.

R51 Item Related to RCK Entry is Ineligible or RCK Entry is Improper

An RCK Entry considered to be ineligible or improper.

R52 Stop Payment on Item Related to RCK Entry

A stop payment order has been placed on the item to which the RCK Entry relates.

R53 Item and RCK Entry Presented for Payment

In addition to an RCK Entry, the item to which the RCK Entry relates has also been presented for payment.

*Effective March 21, 2014

[46]

Common Change Codes

CODE TITLE CORRECTED DATA

C01 Incorrect DFI Account Number Correct DFW Account Number

C02 Incorrect Routing Number Correct Routing Number

C03 Incorrect Routing Number and Incorrect DFI Account Number

Correct Routing Number/Correct DFI Account Number

C04 Incorrect Individual Name/Receiving Company Name*

Correct Individual Name/Receiving Company Name

C05 Incorrect Transaction Code Correct Transaction Code

C06 Incorrect DFI Account Number and Incorrect Transaction Code

Correct DFI Account Number/Correct Transaction Code

C07 Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code

Correct Routing Number/Correct DFI Account Number/Correct Transaction Code

*Effective March 20, 2015, this code will be removed from the Rules.

2015 nacha compliance summary guide · 2018-12-12 · and guidelines. nacha identifies and...

Documents