NACHA Operating Rules ￚ - Goodwin/media/59E1B8A833E54C7082D2...On March 18, 2011, an amendment to the NACHA Operating Rules will become effective that eliminates the requirement

December 3, 2010

TO: ACH Rulebook Subscribers FROM: Cari Conahan, AAP Senior Director, Network Rules

RE: 2010 NACHA Operating Rules ￚ Supplement #2-2010

Application Enhancements FOR YOUR INFORMATION: On November 19, 2010, NACHA’s Voting Membership approved four amendments to the NACHA Operating Rules (“Rules”): Elimination of Opt Out Requirements for ARC and BOC; Collection of Return Fees; Expanded Use of the XCK Application; and Recurring TEL Transactions. The provision regarding ARC and BOC opt out procedures will become effective on March 18, 2011; the other three provisions will become effective on September 16, 2011.

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 2011 Rules language.

Please include these materials with your 2010 edition of the ACH Rules to ensure that your rulebook is up to date. This information will also be available under the supplement tab in both the ACH Rules Online and the 2011 NACHA Operating Rules. Because these amendments were approved just prior to publication of the 2011 edition of the NACHA Operating Rules and Guidelines, the material contained within this Supplement was not able to be included within the main body of the 2011 publication. To ensure compliance with the most current rules, this supplement should be used in tandem with the 2011 Rules. If you have any questions or comments about the enclosed supplement, please feel free to contact NACHA’s Network Rules Department at (703) 561-1100. Attachments

© 2010 NACHA — The Electronic Payments Association®. All rights reserved. No part of this material may be used without the prior written permission of NACHA. This material is not intended to provide any warranties, legal advice, or professional assistance of any kind.

NOTICE OF AMENDMENTS TO THE

NACHA OPERATING RULES

SUPPLEMENT #2-2010 December 3, 2010

1. ELIMINATION OF OPT OUT REQUIREMENTS FOR ARC AND BOC ENTRIES

(Effective March 18, 2011)

2. COLLECTION OF RETURN FEES (Effective September 16, 2011)

3. EXPANDED USE OF XCK APPLICATION

(Effective September 16, 2011)

4. RECURRING TEL TRANSACTIONS (Effective September 16, 2011)

Notice of Amendments to the NACHA Operating Rules Supplement #2-2010; December 3, 2010

Page 2

NACHA OPERATING RULES - SUPPLEMENT #2-2010

On November 19, 2010, NACHA’s Voting Membership approved four amendments to the NACHA Operating Rules (“Rules”): Elimination of Opt Out Requirements for ARC and BOC; Collection of Return Fees; Expanded Use of XCK Application; and Recurring TEL Transactions. The provision regarding ARC and BOC opt out procedures will become effective on March 18, 2011; the other three provisions will become effective on September 16, 2011.

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 2011 Rules language. Because these amendments were approved just prior to publication of the 2011 edition of the NACHA Operating Rules and Guidelines, the material contained within this Supplement will not be included within the main body of the 2011 publication. To ensure compliance with the most current rules, this supplement should be used in tandem with the 2011 Rules.


Page 3

EFFECTIVE MARCH 18, 2011


Page 4

ELIMINATION OF THE OPT OUT REQUIREMENT FOR ARC AND BOC ENTRIES

SUMMARY

On March 18, 2011, an amendment to the NACHA Operating Rules will become effective that eliminates the requirement that Originators of Accounts Receivable Entries (ARC) and Back Office Conversion Entries (BOC) establish and maintain procedures to enable Receivers to opt out of check conversion activity.

Background

The rules implementing Accounts Receivable Entries (ARC) did not originally include a requirement that Originators allow their customers to opt out of check conversion. Although not required by Regulation E, this requirement was added subsequently by the NACHA membership in response to concerns about potential consumer reluctance to have their checks converted, whether because check conversion was new, or because these consumers wanted to receive the original checks with their bank statements. A similar rationale with respect to the consumer’s ability to opt out of check conversion was also applied to the rules governing Back Office Conversion Entries (BOC). Since the adoption of these requirements, however, many Originators of ARC Entries have reported to NACHA that opt out rates are generally 0.1 percent or lower. Such a low rate indicates that consumer concern about check conversion has either not materialized or has dissipated over time. Furthermore, with the increased use of imaging technology, banks generally do not include original checks anymore with their customers’ statements, and consumers who opted out of check conversion may be further confused due to check imaging. With the original reasons for the opt out requirement no longer at issue, eliminating the requirement would simplify processes for existing ARC and BOC Originators, and would remove a barrier to use for potential Originators that have not adopted ARC or BOC. Originators that wish to allow their customers to opt out of ARC and BOC transactions may do so, at their discretion. KEY COMPONENTS OF RULE AMENDMENT

This rule will remove the requirement that Originators of ARC and BOC Entries have procedures in place to allow Receivers to opt out of check conversion. IMPACT TO PARTICIPANTS

Costs to implement this change are expected to be minimal. For most Originators, no systems changes should be required. Existing ARC and BOC Originators that no longer wish to offer opt out should re-evaluate their authorization notices and address any necessary changes to language. Originators ceasing to offer opt out should also consider what actions are necessary with regard to customers who previously opted out of check conversion activity.


Page 5

RDFIs may experience an initial increase in customer service contacts from customers who had previously opted out, or would like to opt out. Any customer service impact initially may be modest and diminish over time.

TECHNICAL SUMMARY

Below is a summary of the impact of this rule change on the 2011 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, subsections 2.5.1.2 (Authorization of ARC Entries by Notification) and 2.5.2.2 (Authorization of BOC Entries by Notification) – removes language from both title and text as it relates to an Originator’s obligation to allow a potential Receiver to opt out of ARC and BOC check conversion activity.

Implementation Date: March 18, 2011

* * * * *

As approved November 19, 2010, effective March 18, 2011, the Rules will be modified as follows for the rule changes eliminating the opt out requirement for ARC and BOC entries:

ARTICLE TWO - RIGHTS AND RESPONSIBILITIES OF ODFIS, THEIR ORIGINATORS AND THIRD-PARTY SENDERS SUBSECTION 2.5.1.2 Authorization of ARC Entries by Notification, and Opt-Out [Authorization of ARC Entries by Notification] An Originator may satisfy the requirement for authorization of an ARC Entry by providing the Receiver a notice meeting the requirements of this subsection and obtaining the Receiver’s Eligible Source Document. The Originator must provide a conspicuous notice to the Receiver that includes the following, or substantially similar, language prior to the receipt of each Eligible Source Document that is used to initiate an ARC Entry: “When you provide a check as payment, you authorize us either to use information from your check to make a one-time electronic fund transfer from your account or to process the payment as a check transaction.” The Originator must establish reasonable procedures allowing notification by a potential Receiver that the receipt of a Check does not authorize the origination of an ARC Entry to the account on which the Check is drawn (i.e., opt out). If such a Receiver provides notice in accordance with the Originator’s reasonable procedures, then the receipt of the Check by the Originator is not a valid authorization of an ARC Entry. [Effective March 18, 2011, this paragraph will be removed, as it will no longer be applicable to ARC Entries.] For an ARC Entry to a non-Consumer Account, Subsection 2.3.3.1 (Agreement to be Bound by the Rules) does not apply.


Page 6

SUBSECTION 2.5.2.2 Authorization of BOC Entries by Notification, and Opt-Out [Authorization of BOC Entries by Notification] An Originator may satisfy the requirement for authorization of a BOC Entry by providing the Receiver a notice meeting the requirements of this subsection and obtaining the Receiver’s Eligible Source Document. The Originator must provide a conspicuous notice to the Receiver that includes the following, or substantially similar, language prior to the receipt of each Eligible Source Document that is used to initiate each BOC Entry: “When you provide a check as payment, you authorize us either to use information from your check to make a one-time electronic fund transfer from your account or to process the payment as a check transaction. For inquiries, please call <retailer phone number>.” The Originator must post the notice in a prominent and conspicuous location and must provide a copy of such notice, or language that is substantially similar, to the Receiver at the time of the transaction. If a potential Receiver notifies the Originator at the point of the in-person transaction that the Receiver does not authorize an electronic funds transfer (i.e., opt-out), then receipt of that specific Check by the Originator is not a valid authorization of a BOC Entry, and the Originator has no obligation under these Rules to accept the Check. [Effective March 18, 2011, this paragraph will be removed, as it will no longer be applicable to BOC Entries.] For a BOC Entry to a non-Consumer Account, Subsection 2.3.3.1 (Agreement to be Bound by the Rules) does not apply.


Page 7

EFFECTIVE SEPTEMBER 16, 2011


Page 8

COLLECTION OF RETURN FEES

SUMMARY

On September 16, 2011, an amendment to the NACHA Operating Rules will become effective that establishes specific authorization and identification requirements for ACH debits used to collect return fees for certain checks and ACH debits that have been returned for insufficient or uncollected funds.

Background

Many merchants and billers assess a return fee to help recover costs associated with the collection of payments returned unpaid, including due to reasons of insufficient or uncollected funds. Return fees are often governed by state law. Currently, 42 states and the District of Columbia explicitly allow for the collection of a return fee when a check is dishonored. The maximum amount of the return fee ranges from $20 to $50, or it may be calculated as a percentage of the face value of the check. Most states require notification to the check writer that a return fee will be assessed if the item is returned unpaid. Currently, the Rules do not differentiate an ACH debit for the collection of a return fee from any other ACH debit. An Originator must obtain the Receiver’s explicit authorization in order to collect the fee via the ACH Network, with the general requirement that the authorization be signed or similarly authenticated. The manner in which authorization is obtained depends upon the application used for the collection of the fee – written authorization is required for a PPD (or WEB if via the Internet). A return fee collected by a TEL Entry would require a separate call and compliance with the TEL rules. By contrast, in a 2006 amendment to Regulation 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 are now more restrictive than the regulation. These differing requirements create challenges for some businesses, particularly with respect to checks, check conversion (ARC and BOC) and check truncation transactions (RCK), where the current written authorization requirements for return fees can present 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 the transactions will be returned unpaid. This represents 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 can be challenging. As a result of this requirement of the Rules,


Page 9

Originators and potential Originators of ACH transactions often use other payment methods, such as Remotely Created Checks, to collect return fees. To the extent that an Originator can use the ACH Network today to collect return fees, the Rules do not currently require that these transactions be specifically identified to the Receiver in any particular manner, nor is there a means to relate the return fee to the underlying transaction that was returned unpaid. This can present challenges to a Receiver in terms of being able to identify a particular transaction as a return fee and in reconciling his account, which can then lead to customer service inquiries for RDFIs. This rule will specifically address authorization and transaction identification requirements for ACH debits used to collect return fees. KEY COMPONENTS OF RULE AMENDMENT

This rule will define and establish a Return Fee Entry as a specific type of ACH Entry, and will establish the parameters for its use, authorization, formatting, and transaction identification. The rule includes a new warranty specific to a Return Fee Entry. Authorization of a Return Fee Entry This rule will create a new debit Entry type - a Return Fee Entry - that will be used only for the purpose of collecting return fees for 1) certain ACH debits to Consumer Accounts1 that are returned for insufficient (“NSF”) or uncollected funds (“UCF”), or 2) other qualifying checks that are returned NSF/UCF. The rule will explicitly define authorization and formatting requirements for a Return Fee Entry. Authorization by Notice The Rule will allow Originators to obtain authorization for a Return Fee Entry by providing the Receiver/check writer with notice that conforms to the requirements of Regulation E at the time that the underlying ACH debit is authorized or the underlying check is accepted. The following are examples of how Originators can obtain authorization for a Return Fee Entry in this manner:

A merchant accepts a check eligible for conversion from a customer but does not convert the check to ACH (i.e., the merchant processes the payment as a check). The merchant can obtain authorization for a Return Fee Entry by posting notice at the point-of-sale in conformance with Regulation E. If the check is returned NSF/UCF, the merchant can originate a Return Fee Entry.

A merchant accepts a check from a consumer and converts it to a BOC Entry. Authorization for the BOC Entry is obtained in conformance with Regulation E and the Rules by posting a conspicuous notice with clear and readily understandable terms, and

1 The rule will also permit Return Fee Entries to non-Consumer Accounts when the original check or the Eligible Source Document for an underlying ARC, BOC or POP transaction does not contain an Auxiliary On-Us field.


Page 10

then obtaining the customer’s signed check. The merchant can obtain authorization for a Return Fee Entry by conforming to the Regulation E requirements in the same notice that served as authorization of the original BOC Entry. If the BOC Entry is returned NSF/UCF, the merchant can originate a Return Fee Entry.

A billing company obtains a written, signed authorization to enroll a customer in monthly Direct Payment, which is collected via a recurring PPD debit. The Originator can obtain authorization for a Return Fee Entry by providing notice in conformance with Regulation E in the authorization for recurring debits. If any PPD debit is returned NSF/UCF, the billing company can originate a Return Fee Entry related to that specific PPD debit.

In each of these cases the Return Fee Entry must bear the PPD Standard Entry Class Code (see discussion below – SEC Codes for a Return Fee Entry). Authorization Other Than by Notice As with the existing Rules, authorization of an ACH debit to collect a return fee also may be obtained in any other form permitted with respect to any SEC Code for a debit Entry to a Consumer Account. Under this rule, a Return Fee Entry authorized in this manner will also need to be properly formatted and identified as a Return Fee Entry (see discussion below). Examples of how an Originator can obtain authorization for a Return Fee Entry in this manner follow:

A merchant accepts a check from a customer and does not convert the check to ACH (i.e., processes as a check). The check is returned NSF/UCF. The merchant subsequently contacts the customer, who agrees to pay a return fee. The merchant’s options for obtaining authorization include:

1. In-person – the merchant directs the customer to return to the store or location, and

obtains written authorization for an ACH debit for the return fee (SEC Code “PPD”); 2. Telephone – the merchant directs the customer to call into a corporate customer

service center, where the customer provides authorization for an ACH debit for the return fee (SEC Code “TEL”);

3. Web site – the merchant directs the customer to a corporate web site, where the customer authorizes an ACH debit for the return fee (SEC Code “WEB”).

A billing company obtains a written, signed authorization to enroll a customer in monthly

Direct Payment, which is collected via a recurring PPD debit. One of the PPD debits is returned NSF/UCF. The biller subsequently contacts the customer, who agrees to pay a return fee. The customer goes to the billing company’s web site and authorizes an ACH debit for the return fee (SEC Code “WEB”).

In each of these cases, the Return Fee Entry must bear the SEC Code appropriate to the manner in which authorization was obtained.


Page 11

Identification of a Return Fee Entry To enable Receivers to identify Return Fee Entries, the rule will require Originators to include the exact words “RETURN FEE” in all capitals in the Company Entry Description field of the Company Batch Header Record, regardless of the manner in which authorization was obtained, the nature of the underlying transaction, or the SEC Code used in the Entry. Because the contents of this field are provided to consumers on their periodic statements, the purpose of the Return Fee Entry will be clear. This method of identification is the same as for other specific types of ACH Entries such as reversals, reclamations, and destroyed checks. In addition, the Originator will be required to identify itself in the Company Name field using the identical name that was used in the underlying ACH debit. If the underlying transaction is a check, the Originator must identify itself with the name by which it is known and readily recognized by the Receiver. This information is also provided to consumers on their periodic statements. Finally, a Return Fee Entry related to any underlying ACH debit that carries a check serial number (ARC, BOC, POP and RCK), or related to an underlying check transaction, must carry the check serial number of the underlying transaction in the Individual Identification Number field2 of the Return Fee Entry. Although some financial institutions provide this information to consumers on their periodic statements, it is not required. The information in this field, however, will be available to RDFIs for purposes of customer service research, and would enable the RDFI and its customer to further recognize the Return Fee Entry and relate it to a specific underlying transaction. Number and Timing of Return Fees The rule will allow an Originator to originate only one Return Fee Entry in relation to an underlying transaction returned NSF/UCF, regardless of the number of times the underlying transaction is returned. For example, an ACH debit can be returned for insufficient funds as many as three times, but the Originator will be allowed to collect only one Return Fee. A Return Fee Entry that is itself returned NSF may be re-initiated in accordance with the rules on re-initiation.3 A Return Fee Entry, however, may not be originated in relation to an underlying ACH debit that is itself a Return Fee Entry (i.e., no return fee on a return fee). 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.

2 Field 7 of PPD Entry; this same field is used as the Check Serial Number field of ARC, BOC, POP and RCK Entries. 3 See 2011 NACHA Operating Rules, Subsection 2.12.4 Reinitiation of Returned Entries.


Page 12

IMPACT TO PARTICIPANTS

This rule may require some ACH participants to make system changes; however, any such changes are anticipated to be minor or moderate in nature. Originators that want to use the ACH Network to collect return fees will need to implement processes, including authorizations and/or notices, that are appropriate to their businesses and practices. Originators, ODFIs and their service providers will need to be able to properly populate the Company Name, Company Entry Description, and Individual Identification fields of Return Fee Entries. RDFIs will need to be able to provide the “RETURN FEE” descriptor contained in the Company Entry Description field to customers.4 RDFIs may want to train customer service and research staff on the significance of the description, and the fact that a related check serial number may be available. RDFIs may experience an initial increase in customer service contacts. Experience suggests that any customer service impact would initially be modest, and then diminish over time. TECHNICAL SUMMARY


Article Two, Section 2.14 (Return Fee Entries) – adds a new section to the rules specific to the collection of return fees via the ACH Network; included within this new section are specific subsections addressing the general rule on Return Fee Entries, authorization requirements, formatting requirements, additional requirements, and an additional ODFI warranty.

Article Eight – Definitions of Terms Used in These Rules Section 8.79 (Return Fee) – adds Return Fee to the list of defined terms. Section 8.80 (Return Fee Entry) – adds Return Fee Entry to the list of defined terms.

Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – revises the following field descriptions/inclusion requirements:

Company/Entry Description – requires a specific descriptive statement when the batch contains Return Fee Entries;

Company Name – requires a Return Fee Entry to contain the same Originator name as the underlying Entry or same name as the payee of the check;

Individual Identification Number – for a Return Fee Entry related to an ARC, BOC, or POP Entry or to an item that was eligible to be converted to a debit Entry but was

4 The contents of this field are already required under the Rules to be provided to customers.


Page 13

not converted, this field must contain the check serial number contained within the ARC, BOC, or POP Entry or item.

Implementation Date: September 16, 2011

* * * * *

As approved November 19, 2010, effective September 16, 2011, the Rules will be modified as follows for the rule changes establishing Return Fee Entries:

ARTICLE TWO - RIGHTS AND RESPONSIBILITIES OF ODFIS, THEIR ORIGINATORS AND THIRD-PARTY SENDERS [SECTION 2.14 Return Fee Entries SUBSECTION 2.14.1 General Rule for Return Fee Entries An Originator may originate a Return Fee Entry, to the extent permitted by applicable Legal Requirements, in relation to the return of:

(a) a debit Entry to a Consumer Account of a Receiver; (b) an ARC, BOC or POP Entry to a non-Consumer Account of a Receiver; or (c) an item that was eligible to be converted to a debit Entry, but was not converted to an Entry.

For a Return Fee Entry based on the return of an Entry, the Entry must have been returned for insufficient or uncollected funds under the return codes R01 or R09. For a Return Fee Entry based on the return of a Check, the returned Check must be marked to indicate that it was returned due to “Not Sufficient Funds, “ NSF,” “Uncollected Funds,” or comparable language. SUBSECTION 2.14.2 Authorization of Return Fee Entries An Originator may satisfy the requirements for authorization of the Return Fee Entry by providing notice, at the time that the underlying Entry is authorized or the original item is accepted, of the Return Fee Entry in form, process and content permissible under Regulation E, regardless of whether the account to be debited is a Consumer Account or a non-Consumer Account. The notice must include the following, or substantially similar, language:

“If your payment is returned unpaid, you authorize us to make a one-time electronic fund transfer from your account to collect a fee of [$ ];” or


Page 14

“If your payment is returned unpaid, you authorize us to make a one-time electronic fund transfer from your account to collect a fee. The fee will be determined [by/as follows]: [ ].”

SUBSECTION 2.14.3 Formatting Requirements for Return Fee Entries A Return Fee Entry authorized by notice in accordance with Subsection 2.14.2 (Authorization of Return Fee Entries) must use the Standard Entry Class Code “PPD.” A Return Fee Entry authorized in a manner other than by notice must use the Standard Entry Class Code appropriate to the manner of authorization. An Originator must submit Return Fee Entries as a separate batch that contains the words “RETURN FEE” in the Company Entry Description field of the Company/Batch Header Record. The Company Name field of a Return Fee Entry 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. SUBSECTION 2.14.4 Other Requirements of Return Fee Entries An Originator may impose only one Return Fee in relation to an underlying Entry or item that was returned, whether such Return Fee is collected via the ACH or otherwise. An Originator may re-initiate a Return Fee Entry in accordance with Subsection 2.12.4 (Reinitiation of Returned Entries), but an Originator may not originate a Return Fee Entry with respect to the return of another Return Fee Entry. A Return Fee Entry authorized by notice in accordance with Subsection 2.14.2 (Authorization of Return Fee Entries) must have a Settlement Date within 45 days of the Settlement Date of the Return Entry of the underlying debit Entry or the return of the other underlying item. SUBSECTION 2.14.5 Additional ODFI Warranty for Return Fee Entries In addition to the other warranties contained within these Rules, an ODFI initiating a Return Fee Entry warrants to each RDFI and ACH Operator that the Originator imposing the Return Fee has not and will not impose any other Return Fee in relation to the underlying Entry or item that was returned unpaid.] ARTICLE EIGHT - DEFINITIONS OF TERMS USED IN THESE RULES [SECTION 8.79 “Return Fee” A fee charged by an Originator to a Receiver for a debit Entry or other item that was returned for insufficient or uncollected funds, to the extent permitted by applicable Legal Requirements.]


Page 15

[SECTION 8.80 “Return Fee Entry” A Single Entry initiated by an Originator to the account of a Receiver to collect a Return Fee.] APPENDIX THREE – ACH RECORD FORMAT SPECIFICATIONS PART 3.2 Glossary of ACH Record Format Data Elements SUBPART 3.2.2 Glossary of Data Elements 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. 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


Page 16

must contain the name by which the payee is known to and readily recognized by the Receiver of the Entry. In a 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.

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). Individual Identification Number: 15 Positions – Entry Detail Record – Optional (DNE, POS, PPD, TEL, WEB, Returns, dishonored Returns, contested dishonored Returns, COR, refused COR); 22 Positions – Entry Detail Record – Mandatory (CIE, MTE) Except as otherwise noted below, this field contains the accounting number by which the Receiver is known to the Originator. It is included for further identification and for descriptive purposes. The RDFI should assume no specific format to be present (e.g., presence or absence of dashes), but can assume that the field is pre-edited so that it is suitable for description as is (including blanks in unused positions). CIE: This field contains the accounting number by which the Originator (payor) is known to the Receiver (payee). It is used by the Receiver to update accounts receivable Records. It should be the number shown on an invoice, statement, billhead, notice or other communication as the reference. Numbers may be policy, customer, invoice, meter, sequence and/or alphanumeric combinations. Field 8, rather than Field 7, of the Entry Detail Record is used for the Individual Identification Number.


Page 17

MTE: Field 8, rather than Field 7, of the Entry Detail Record is used for the Individual Identification Number. [PPD: For a Return Fee Entry related to an ARC, BOC, POP, or RCK Entry or to an item that was eligible to be converted to a debit Entry but was not converted, this field must contain the check serial number contained within the ARC, BOC, POP, or RCK Entry or item.]


Page 18

EXPANDED USE OF THE XCK APPLICATION

SUMMARY

On September 16, 2011, an amendment to the NACHA Operating Rules will become effective that expands the scope of the Destroyed Check Entry (XCK) application to permit its use for certain damaged checks that cannot be imaged, or other check images that cannot be processed. Such additional items include images that cannot be processed through an image exchange, and items that are sufficiently damaged so that they cannot be processed or used to create an image. In each case, these items contain sufficient information to process as an ACH Entry. Although there may be check image exchange or clearing house rules to address damaged checks or images, such rules do not apply to financial institutions that do not belong to such exchanges. The use of the ACH Network to clear such items provides a cost-effective option for all financial institutions.

KEY COMPONENTS OF RULE AMENDMENT

XCK Eligibility Requirements The current use of XCK for clearing checks contained within a cash letter that has been lost or destroyed, and the existing dollar limit of $2,500, will be retained. This rule will revise the definition of, and general rule for, Destroyed Check Entries to also allow their use to collect certain damaged checks for which processable images cannot be made and certain check images that are unprocessable.

The XCK eligibility requirements will be expanded to incorporate the following examples of items that are damaged or unable to be processed as images that would be eligible for collection via the ACH Network: A check missing part of the MICR line but that can be sufficiently repaired to create an ACH

debit; A check that, in whole or in part, is unreadable, obscured, or mutilated in a manner that

prevents automated check processing or creation of an image that may be used to produce a “substitute check” under the Check 21 Act, but has an intact MICR line;

A check that does not pass standard quality tests for creation of an image that may be used to

produce a substitute check under Check 21. An ODFI will warrant that the item used to initiate an XCK Entry is eligible. The ODFI will also warrant that is has the authority to initiate the XCK. An ODFI may need to review its agreements with depositors and other banks in the collection process to ensure it has such authority.


Page 19

Optional Acceptance of XCK Entries

The use of XCK for the purpose of clearing these types of items will be optional for both ODFIs (Collecting Banks) and RDFIs (Paying Banks). RDFIs will retain their right to return XCK Entries for any reason for up to 60 days following the Settlement Date.


ODFIs that want to use the XCK application for this purpose would need to be able to populate the ACH formats from captured MICR information. ODFIs may need to review deposit agreements and agreements with other banks in the collections process to ensure they have the necessary authority to initiate XCK entries. RDFIs may need to review their policies regarding acceptance of XCK Entries, and ensure that processes are in place to post or return the XCK Entries in conformance with their policies. TECHNICAL SUMMARY


Article Two, Subsection 2.5.18.1 (General Rule for XCK Entries) – revises the general rule on XCK entries to eliminate redundant language related to eligibility criteria.

Article Two, Subsection 2.5.18.2 (XCK Eligible Items) – expands the eligibility criteria for XCK entries to incorporate use of the application for checks (including images of those checks) that have missing or damaged MICR lines or images that prevent the processing of those items through check or image clearing mechanisms.

Article Two, Subsection 2.5.18.4 (Provision of Copy of Item to RDFI or Other DFI) – Requires the ODFI to provide a copy of the item to which the XCK Entry relates to the first DFI to which such item was transferred, if different than the ODFI.

Article Two, Subsection 2.5.18.5 (Additional Warranties for XCK Entries) – incorporates a reference to an image within the warranty that the item to which the XCK Entry relates has not been presented; adds an additional warranty that the ODFI has all necessary authority to initiate the XCK entry, and that the item to which the XCK entry relates satisfies the eligibility requirements of the Rules.

Article Eight – Definitions of Terms Used in These Rules Section 8.25 (Destroyed Check Entry/XCK Entry/XCK) – revises the definition of

Destroyed Check Entry to eliminate language specific to eligibility criteria. Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – revises the following field

descriptions/inclusion requirements: Standard Entry Class – revises the description of the XCK SEC Code to eliminate

redundant language defined under eligibility criteria. Implementation Date: September 16, 2011


Page 20

* * * * *

As approved November 19, 2010, effective September 16, 2011, the Rules will be modified as follows for the rule changes expanding XCK eligibility:

ARTICLE TWO - RIGHTS AND RESPONSIBILITIES OF ODFIS, THEIR ORIGINATORS AND THIRD-PARTY SENDERS SUBSECTION 2.5.18.1 General Rule for XCK Entries If an eligible item as described in Subsection 2.5.18.2 (XCK Eligible Items) is contained within a cash letter that has been lost, destroyed, or is otherwise unavailable to, and cannot be obtained by, an ODFI, the ODFI may initiate an XCK Entry for that item. Notwithstanding Section 8.33 (“Entry”), an XCK Entry shall not be deemed to be an item under Article 4 of the Uniform Commercial Code, and neither Transmittal to nor receipt by an RDFI of an XCK Entry shall constitute presentment of the destroyed item. [An ODFI may originate an XCK entry for an eligible item as described in Subsection 2.5.18.2 (XCK 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 Code, and neither Transmittal to nor receipt by an RDFI of an XCK Entry shall constitute presentment of the original item.] SUBSECTION 2.5.18.2 XCK Eligible Items An ODFI may initiate an XCK Entry only in relation to an item that is:

(a) an item within the meaning of Article 4 of the Uniform Commercial Code; (b) a negotiable demand draft drawn on or payable through or at an office of a

Participating DFI, other than a Federal Reserve Bank or Federal Home Loan Bank; (c) in an amount less than $2,500; and (d) lost, destroyed, or otherwise unavailable while in transit for presentment to a paying

bank. [An ODFI may initiate an XCK Entry only in relation to an item that:

(a) is an item within the meaning of Article 4 of the Uniform Commercial Code; (b) is a negotiable demand draft drawn on or payable through or at an office of a

Participating DFI, other than a Federal Reserve Bank or Federal Home Loan Bank; (c) is in an amount less than $2,500; and (d) either (1) is contained within a cash letter that is lost, destroyed, or otherwise

unavailable while in transit for presentment to a paying bank, and cannot be obtained; or (2) (A) is missing part of the MICR line but can be sufficiently repaired to create an ACH Entry; (B) is an image of an item that cannot be processed through the applicable image exchange, but has sufficient information to create an Entry; or (C) is, in whole or in part, unreadable, obscured, or mutilated in a manner that


Page 21

prevents automated check processing or creation of an image that can be used to produce a “substitute check” that is the legal equivalent of the original check under the Check Clearing for the 21st Century Act, Pub. L. 108-100, but has sufficient information to create an Entry.]

SUBSECTION 2.5.18.4 Provision of Copy of Item to RDFI [Provision of Copy of Item to RDFI or Other DFI] An ODFI must provide a copy of the item to which the XCK Entry relates to the RDFI within thirty days of receiving a written request from the RDFI, provided that such request is received within six years of the date on which the ODFI initiated the XCK Entry. [An ODFI must provide a copy of the item to which the XCK Entry relates to the RDFI, and to the first DFI to which such item was transferred if different from the ODFI, within thirty days of receiving a written request from the RDFI or such other DFI, respectively, provided that such request is received within six years of the date on which the ODFI initiated the XCK Entry.] SUBSECTION 2.5.18.5 Additional ODFI Warranties for XCK Entries In addition to the other warranties contained within these Rules, an ODFI originating an XCK Entry warrants to each RDFI, ACH Operator, and Association that:

(a) Good Title to the Destroyed Check. [Good Title to the Check.] The ODFI has good title to or is entitled to enforce the item to which the XCK Entry relates or is authorized to obtain payment or acceptance on behalf of one who has good title or is entitled to enforce the item. (b) Signatures are Genuine. All signatures on the item to which the XCK Entry relates are authentic and authorized. (c) No Alterations. The item to which the XCK Entry relates has not been altered. (d) No Defenses. The item to which the XCK Entry relates is not subject to a defense or claim in recoupment of any party that can be asserted against the ODFI.

(e) No Knowledge of Insolvency. The ODFI has no knowledge of any insolvency proceeding commenced with respect to the maker or acceptor or, in the case of an unaccepted draft, the drawer of the item to which the XCK Entry relates. (f) Item Drawn on RDFI. The item to which the XCK Entry relates is drawn on, payable through, or payable at the RDFI. (g) XCK Entry Accurately Reflects Item. The amount of the item to which the XCK Entry relates, the item number, and account number contained on such item have been accurately reflected in the XCK Entry.


Page 22

(h) Item Has Not Been Presented. Neither the item to which the XCK Entry relates, nor any copy of such item, has been presented and will not be presented to the RDFI. [Neither the item to which the XCK Entry relates, nor any copy (including any image) of such item, has been presented and will not be presented to the RDFI.]

[(i) Authority and Eligibility. The ODFI has all necessary authority to initiate the XCK Entry, and the item to which the XCK Entry relates satisfies the eligibility requirements of Subsection 2.5.18.2 (XCK Eligible Items).]

ARTICLE EIGHT - DEFINITIONS OF TERMS USED IN THESE RULES SECTION 8.25 “Destroyed Check Entry” or “XCK Entry” or “XCK” a debit Entry initiated in the event an eligible item described in Subsection 2.5.18.2 (XCK Eligible Item) is contained within a cash letter that is lost, destroyed, or otherwise unavailable to and cannot be obtained by an ODFI. [a debit Entry initiated with respect to an item described in Subsection 2.5.18.2 (XCK Eligible Item).] APPENDIX THREE – ACH RECORD FORMAT SPECIFICATIONS PART 3.2 Glossary of ACH Record Format Data Elements SUBPART 3.2.2 Glossary of Data Elements Standard Entry Class: 3 Positions – Company/Batch Header – Mandatory (all batches) This field contains a three-character code used to identify various types of Entries.

ACK: ACH Payment Acknowledgment - The code that identifies a Non-Monetary Entry initiated by an RDFI to provide an acknowledgment of receipt by the RDFI of a corporate credit payment originated using the CCD format. ADV: Automated Accounting Advice - The code that identifies a Non-Monetary Entry that is used by an ACH Operator to provide accounting information regarding an Entry to Participating DFIs in machine readable format. An Automated Accounting Advice is an optional service provided by ACH Operators and must be requested by a DFI desiring this service. ARC: Accounts Receivable Entry – The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account based on an Eligible Source Document provided to the Originator by the Receiver via the U.S. mail or at a dropbox location. ATX: Financial EDI Acknowledgment - The code that identifies a Non-Monetary Entry initiated by an RDFI to provide an acknowledgment of receipt by the RDFI of a corporate credit payment originated using the CTX format. BOC: Back Office Conversion Entry – The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account 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.


Page 23

CCD: Corporate Credit or Debit Entry - The code that identifies an Entry initiated by an Organization to transfer funds to or from an account of that Organization or another Organization. CIE: Customer Initiated Entry - The code that identifies a credit Entry initiated by or on behalf of the holder of a Consumer Account to transfer funds to the account of the Receiver. COR: Notification of Change or Refused Notification of Change - The code that identifies a Non-Monetary Entry Transmitted by (1) an RDFI for the purpose of identifying incorrect information contained within an Entry and providing correct data in the precise format to be used on future Entries, or (2) an ODFI to refuse a misrouted NOC or an NOC that contains incorrect information. CTX: Corporate Trade Exchange - The code that identifies an Entry initiated by an Organization to transfer funds to or from the account of that Organization or another Organization that permits the inclusion of payment related remittance information in ANSI or UN/EDIFACT syntax. DNE: Death Notification Entry - The code that identifies a Non-Monetary Entry initiated by an agency of the Federal Government of the United States to notify an RDFI of the death of a Receiver. ENR: Automated Enrollment Entry - The code that identifies a Non-Monetary Entry initiated by a Participating DFI to an agency of the Federal Government of the United States on behalf, and at the request, of an account holder at the Participating DFI to enroll in a service that will enable Entries to such Person’s account at the Participating DFI. IAT: International ACH Transaction - The code that identifies an Entry that is part of a payment transaction involving a Financial Agency’s office that is not located in the territorial jurisdiction of the United States. An office of a Financial Agency is involved in the payment transaction if it (1) holds an account that is credited or debited as part of the payment transaction, (2) receives payment directly from a Person or makes payment directly to a Person as part of the payment transaction, or (3) serves as an intermediary in the settlement of any part of the payment transaction. MTE: Machine Transfer Entry - The code that identifies Entries initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds to or from a Consumer Account maintained with an RDFI, i.e., an ATM cash deposit or withdrawal. POP: Point-of-Purchase Entry - The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account based on an Eligible Source Document provided to the Originator by the Receiver at the point-of-purchase or manned bill payment location to transfer funds from the Receiver’s account. POS: Point of Sale Entry - The code that identifies a debit Entry initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds from a Consumer Account of the Receiver to pay an obligation incurred in a point-of-sale transaction, or to effect a point-of-sale terminal cash withdrawal. PPD: Prearranged Payment and Deposit Entry - The code that identifies an Entry initiated by an Organization based on a standing or a Single Entry authorization from a Receiver to transfer funds to or from a Consumer Account of the Receiver. RCK: Re-presented Check Entry - The code that identifies a Single Entry debit constituting a presentment notice of an item eligible under Article Two, Subsection 2.5.13.3 (RCK Eligible Items). An RCK Entry is an item as defined by Revised Article 4


Page 24

of the Uniform Commercial Code (1990 Official Text) only for the limited purposes of presentment as set forth in Article 4-110(c) and notice of dishonor as set forth in Article 4-301(a)(2). SHR: Shared Network Transaction - The code that identifies a debit Entry initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds from a Consumer Account of the Receiver to pay an obligation incurred in a point-of-sale transaction, or to effect a point-of-sale terminal cash withdrawal. SHR Entries are initiated in a shared network where the ODFI and RDFI have an agreement in addition to these Rules to process such Entries. TEL: Telephone-Initiated Entry - The code that identifies a Single-Entry debit initiated by an Originator pursuant to an oral authorization obtained over the telephone to transfer funds from a Consumer Account of the Receiver. TRC: Check Truncation Entry - The code that identifies a debit Entry initiated pursuant to a Check Truncation Program that permits the Truncation of a single Check drawn on the paying bank. TRX: Check Truncation Entries Exchange - The code that identifies a debit Entry initiated based on a Check Truncation Program that permits the Truncation of multiple Checks drawn on the same paying bank. WEB: Internet-Initiated/Mobile Entry - The code that identifies a debit Entry initiated by an Originator to a Consumer Account of the Receiver based on (1) an authorization that is communicated, other than by an oral communication, from the Receiver to the Originator via the Internet or a Wireless Network, or (2) any form of authorization if the Receiver’s instruction for the initiation of the individual debit Entry is designed by the Originator to be communicated, other than by an oral communication, to the Originator via a Wireless Network. XCK: Destroyed Check Entry - The code that identifies a debit Entry initiated in the event an item eligible under Article Two, subsection 2.5.18.2 (XCK Eligible Items) is contained within a cash letter that is lost, destroyed, or otherwise unavailable to and cannot be obtained by the ODFI. [The code that identifies a debit Entry initiated with respect to an item eligible under Article Two, subsection 2.5.18.2 (XCK Eligible Items).]


Page 25

RECURRING TEL TRANSACTIONS

SUMMARY

On September 16, 2011, an amendment to the NACHA Operating Rules will become effective that expands the scope of the TEL application to permit its use for recurring consumer transactions.

Background

The existing Telephone-Initiated Entry (TEL) application enables an Originator to obtain oral authorization from a consumer over the telephone for a single-entry ACH debit. The TEL application, as implemented in 2001, was modeled after the Federal Trade Commission’s (FTC) Telemarketing Sales Rule of 1995, which established a framework for allowing paper drafts to be authorized over the telephone for certain types of transactions. The Telemarketing Sales Rule specified the type of authorization that the seller or telemarketer needs to obtain before submitting for payment a check, draft or other form of negotiable paper drawn on a person’s checking, savings, share or similar account. The FTC defined an authorization as one in which 1) the consumer’s express oral authorization is audio-recorded and made available upon request to the customer’s financial institution, or 2) written confirmation of the transaction is provided to the consumer. At the time it was adopted, the TEL application was restricted to single Entries in order to conform to the requirements of the Federal Reserve Board’s Official Staff Interpretations of Regulation E (Commentary). Prior to 2006, the Commentary explicitly stated that an audio-recording of a consumer’s oral authorization taken over the telephone did not constitute authorization for preauthorized (recurring) debits. This prohibition was removed from the Commentary in 2006. As a result, the Rules are now more restrictive than Regulation E. The restriction of TEL to single Entries prevents Originators from using the ACH Network in some scenarios. For example, when establishing a new billing relationship, a biller may want to establish recurring payments while the new customer is on the telephone. Because recurring TEL transactions are not available, the biller would have to direct the consumer to its website, send an enrollment/authorization (processes that reduce electronic payment enrollment rates), or use a different method of payment, such as remotely created checks (“RCCs”). This rule will expand the scope of the TEL application to permit its use for recurring debits.5 An Originator using TEL for recurring debits will have to ensure that the oral authorization complies with Regulation E’s writing and signature requirements for preauthorized transfers. With respect

5 Only clarifying changes will be made to the rules regarding Single Entry TEL. These changes are not intended to have any substantive effect.


Page 26

to the question of what constitutes a “writing” that is “signed or similarly authenticated” by the consumer, the Commentary provides that Regulation E’s writing and signature requirements for preauthorized transfers can be satisfied by compliance with the Electronic Signatures in Global and National Commerce Act (“e-Sign”), which provides for legal equivalence of electronic records and electronic signatures with their physical counterparts. Thus, an Originator using recurring TEL will have to ensure that its authorizations, including, for example, the use of a recorded telephone conversation, are in compliance with the e-Sign Act. KEY COMPONENTS OF RULE AMENDMENT

TEL Entry Definition and Applicability This rule will revise the definition of, and the general rule for, TEL Entries to incorporate both Single Entry and recurring debit Entries authorized orally via the telephone. Authorization Requirements This amendment will also expand the specific authorization language for TEL Entries to address authorization requirements for recurring TEL Entries in conformance to the requirements of Regulation E. (Note: Minor changes to language governing authorization requirements for Single-Entry TEL Entries will also be made for consistency and clarity.) While Receivers typically are identified by name in an authorization, the rule also 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. Authorizations for recurring TEL Entries will need to meet the writing and signature requirements of Regulation E for preauthorized transfers, which can be done by conforming to the e-Sign Act. Neither Regulation E nor the Commentary, however, provides additional guidance as to how Originators can comply with e-Sign. Although NACHA cannot formally interpret Regulation E, guidance is included below that provides additional information to Originators on how to comply with the Rules for authorization of recurring TEL entries. This guidance is not intended to be legal advice regarding compliance with Regulation E. Originators using recurring TEL will still be responsible for determining their own compliance with Regulation E and the e-Sign Act.

_________________________________________________________________

NACHA GUIDANCE ON RECURRING TEL ENTRY AUTHORIZATION The NACHA Rules permit recurring debit Entries to be originated by telephone using the TEL Entry SEC Code. As with Single Entry TEL Entries, a recurring TEL Entry may be initiated only when there is an Existing Relationship between the Originator and the Receiver or the Receiver initiates the telephone call to the Originator.


Page 27

For purposes of complying with the NACHA Rules, the authorization requirements for recurring TEL Entries may be satisfied if the Originator (1) creates a recording of the oral authorization of the Receiver that satisfies the requirements described below, including via a live operator or automated voice response unit; and (2) sends a written copy of the authorization to the Receiver prior to the Settlement Date of the first Entry originated in accordance with the authorization.

The oral authorization must: be readily identifiable as an authorization of a recurring transfer from the

Receiver’s account; state the terms of the recurring transfer clearly and in readily understandable

terms; evidence the Receiver’s identity; and evidence the Receiver’s assent to the authorization.

To satisfy such requirements, the authorization of the Receiver recorded by the

Originator must include: the name or identity of the Receiver; a telephone number for Receiver inquiries that is answered during normal

business hours; the date of the Receiver’s oral authorization; specific authorization language; the account to be debited; the timing, number and/or frequency of the debits; and the amount of the debit, or reference the method of determining the amount of

recurring transfers.

Originators and ODFIs also must ensure that their method of obtaining authorization for recurring debits to a consumer account complies with Regulation E.

Telephonic Authorization of a Recurring Debit to a Consumer Account under Regulation E and e-Sign Act Under the Rules, an ODFI is responsible for the compliance of the telephonic authorization process with applicable law and for the validity of any authorization obtained using such a process. To facilitate ACH participants’ consideration of such processes, two distinct situations that might be faced by entities considering whether to permit consumers to authorize recurring ACH debits from their accounts via the telephone are outlined below at a high-level. The first scenario is based on the Rules as they existed prior the effective date of the recurring TEL rule (September 16, 2011), and results in “telephone-initiated PPD transactions” in which a written authorization is electronically signed; the second is based on


Page 28

the rule for recurring TEL payments with an oral authorization. Of course there are many other permutations of the scenarios below that individual Originators and ODFIs may wish to consider. SCENARIO 1 – TELEPHONE-INITIATED PPD ENTRIES BY ELECTRONICALLY

SIGNED AUTHORIZATION The consumer has received clear and readily understandable terms of the preauthorized transfer in writing (either in a physical writing or in an electronic manner that satisfies e-Sign Act or other applicable law) prior to the telephone call. The writing includes spaces for the consumer to record any variable information (e.g., transaction amount, transaction frequency, account number and/or routing and transit number). The consumer then initiates a telephone call to the Originator, during which the consumer authorizes a recurring debit to his or her consumer account, and “signs” the written authorization either by inputting a code into the telephone keypad or by providing orally to a customer service representative. This scenario could be applicable to an existing billing relationship, in which the billing company regularly sends bills in writing (either paper or electronic) to an existing customer. The bill would contain the clear and readily understandable terms of the preauthorized transfers, and a code for the customer to input during the telephone call. SCENARIO 2 – RECURRING TEL ENTRIES BY ORAL AUTHORIZATION The consumer has not received the terms of the preauthorized transfer in writing (either in a physical writing or in an electronic manner that satisfies e-Sign Act or other applicable law) prior to the telephone call. The consumer initiates a telephone call to the Originator, during which the consumer authorizes a recurring debit to his or her consumer account. The consumer provides his or her authorization, including his or her “signature” or “authentication” of the authorization, via a recorded conversation. The consumer either repeats or expressly confirms the authorization, including the account to be debited, the timing of the debits (e.g., monthly on the 1st business day of the month), and the amount (e.g., $50.00 per month), as well as other required elements of the authorization. The Originator sends a written confirmation of the authorization to the consumer (either in a physical writing or in an electronic manner that satisfies e-Sign Act or other applicable law). This scenario could be applicable to both: 1) an existing billing relationship in which terms of the preauthorized transfer are not contained in writing on a bill; and 2) a new billing relationship in which a new customer wants to authorize recurring payments on the same telephone call that establishes a new service (e.g., a new car insurance policy). _________________________________________________________________


Page 29

Modifications to TEL Entry Detail Record The Entry Detail Record format for TEL Entries will be modified to replace the 2-character Discretionary Data field with a new Payment Type Code field. An indicator will be required to identify the entry as recurring or single. Similar to WEB Entries, the Payment Type Code field for recurring TEL Entries will include a value of “R.” For Single-Entry TELs, however, Originators will be able to populate this field with either an “S” or space-fill the field. This will minimize any software impacts on current users of Single-Entry TEL Entries. Use of Return Reason Code R07 (Authorization Revoked by Customer) for TEL (and WEB) Entries This amendment will remove limitations on the RDFI’s use of Return Reason Code R07, allowing it to be used to return TEL and WEB Entries. These changes will support the return of recurring TEL debits for which authorization can be revoked. Additionally, technology and industry practices have advanced such that Single-Entry TEL and WEB payments may be scheduled in advance so that there is sufficient time for a Receiver to revoke authorization. For example, a consumer receives a credit card statement showing a specific amount due by a specific date. In today’s processing environment, it is common for the card issuer to allow the customer to go onto its website, or call on the phone, and schedule a payment for the amount due on the due date. This can happen several weeks in advance. There is sufficient time available for a Receiver to be able to revoke this authorization; therefore, although not directly related to the Rule to establish recurring TEL, the Rule eliminates this limitation in the use of R07.


Originators that want to use recurring TEL will be required to implement authorization procedures that are compliant with the Rules, Regulation E, and the e-Sign Act, including written confirmations, and that comply with applicable legal requirements. Use of recurring TEL, however, is optional by Originators. ODFIs, RDFIs and ACH Operators will need to modify their ACH software to accommodate the revisions to the TEL Entry Detail Record, which will require replacement of the existing Discretionary Data field with a new Payment Type Code field and the inclusion of appropriate indicators. Any ODFIs and RDFIs that have software restrictions on the use of R07 for TEL and WEB entries will need to remove those limitations and ensure that these types of returns will be processed.


Page 30

TECHNICAL SUMMARY


Article Two, Subsection 2.5.15.1 (General Rule for TEL Entries) – deletes language that restricts TEL usage to Single Entry transactions only.

Article Two, Subsection 2.5.15.2 (Authorization of TEL Entries) – establishes authorization requirements for recurring TEL transactions; makes minor clarifying and conforming changes to authorization requirements for Single Entry TEL transactions.

Article Two, Subsection 2.5.15.3 (Retention of the Record of Authorization for TEL Entries) – revises record retention requirements for TEL Entries to incorporate requirements for recurring TEL transactions.

Article Two, Subsection 2.5.15.5 (Rules Exceptions for TEL Entries) – adds a new subsection to the rules to exempt TEL Entries from the requirement that an electronic authorization be visually displayed in a manner that enables the consumer to read the communication.

Article Eight – Definitions of Terms Used in These Rules Section 8.89 (Telephone-Initiated Entry/TEL Entry/TEL) – revises the definition of

Telephone-Initiated Entry to accommodate its use for recurring Entries. Appendix Three, Subpart 3.1.20 (Sequence of Records for TEL Entries) – revises the TEL

Entry Detail Record layout to re-define positions 77-78 as a Payment Type Code field. Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – revises the following field

descriptions/inclusion requirements: Discretionary Data – removes TEL entries from the list of SEC Codes containing this

field, as the use of these data positions has been re-defined under this proposal; Payment Type Code – includes TEL within the list of SEC Codes containing this

field; expands the description of the field to include references to TEL Entries; Standard Entry Class –revises the description of the TEL SEC Code to incorporate

recurring transactions. Appendix Four, Part 4.2 (Table of Return Reason Codes) – revises the “Notes” section of

Return Reason Code R07 (Authorization Revoked by Customer) to remove TEL (and WEB as a related issue) from the restrictions on the use of this return code.

Implementation Date: September 16, 2011

* * * * *


Page 31

As approved November 19, 2010, effective September 16, 2011, the Rules will be modified as follows for the rule changes expanding the TEL application:

ARTICLE TWO - RIGHTS AND RESPONSIBILITIES OF ODFIS, THEIR ORIGINATORS AND THIRD-PARTY SENDERS SUBSECTION 2.5.15.1 General Rule for TEL Entries A TEL Entry is a debit Entry originated based on an oral authorization provided to the Originator by a Receiver via the telephone. A TEL Entry may only be used for a Single Entry for which there is no standing authorization for the origination of ACH entries to the Receiver’s account. [Effective September 16, 2011, the preceding sentence will no longer be applicable to TEL Entries and will be removed.] A TEL Entry may only be used when there is an Existing Relationship between the Originator and the Receiver, or, when there is not an Existing Relationship between the Originator and the Receiver, when the Receiver initiates the telephone call. An ODFI must perform, or ensure that its Originator or Third-Party Sender performs, the requirements of Subsection 2.5.15.2 and Subsection 2.5.15.3 below before permitting the Originator or Third-Party Sender to initiate a TEL Entry. SUBSECTION 2.5.15.2 Authorization of TEL Entries An Originator must satisfy the requirement for authorization of a TEL Entry by obtaining oral authorization from the Receiver to initiate a debit Entry to a Consumer Account of the Receiver. 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: [The following minimum information must be included as part of the authorization of a Single Entry TEL Entry:]

a) the date on or after which the ACH debit to the Receiver’s account will occur; b) the amount of the transaction; [the amount of the transaction or a reference to the

method of determining the amount of the transaction;] c) the Receiver’s name; [the Receiver’s name or identity;] d) [the account to be debited;] e) a telephone number for Receiver inquiries that is answered during normal business

hours; f) the date of the Receiver’s oral authorization; and g) a statement by the Originator that the authorization obtained from the Receiver is for

a Single-Entry ACH debit, a one-time electronic funds transfer, or other similar reference.

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


Page 32

Entry. [For an authorization relating to a Single Entry TEL Entry, 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 following minimum information must be included as part of the authorization of a recurring TEL Entry:

h) the amount of the recurring transactions, or a reference to the method of determining the amounts of recurring transactions;

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

j) the Receiver’s name or identity; k) the account to be debited; l) a telephone number for Receiver inquiries that is answered during normal business

hours; and m) 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.] SUBSECTION 2.5.15.3 Retention of the Record of Authorization for TEL Entries An Originator must retain the original or a copy of the written notice or the original or a duplicate audio recording of the oral authorization for two years from the date of the authorization. [An Originator must retain the original or a copy of the written notice or the original or a duplicate audio recording of the oral authorization for two years from the date of the authorization of a Single Entry TEL Entry or from the termination or revocation of the authorization for recurring TEL Entries.]

[SUBSECTION 2.5.15.5 Rules Exceptions for TEL Entries The requirement that an Electronic authorization must be visually displayed in a manner that enables the consumer to read the communication, as required by Subsection 2.3.2.4 (Electronic Authorization), does not apply to TEL Entries.]


Page 33

ARTICLE EIGHT - DEFINITIONS OF TERMS USED IN THESE RULES SECTION 8.89 “Telephone-Initiated Entry” or “TEL Entry” or “TEL” a Single Entry debit initiated by an Originator to a Consumer Account of the Receiver based on an oral authorization obtained over the telephone. [a debit initiated by an Originator to a Consumer Account of the Receiver based on an oral authorization obtained over the telephone.] APPENDIX THREE – ACH RECORD FORMAT SPECIFICATIONS PART 3.2 Glossary of ACH Record Format Data Elements SUBPART 3.2.2 Glossary of Data Elements Discretionary Data: 2 Positions – Entry Detail Record, Corporate Entry Detail Record – Optional (ACK, ADV, ARC, ATX, BOC, CCD, CIE, CTX, DNE, MTE, POP, PPD, RCK, TEL, XCK, Returns, dishonored Returns, contested dishonored Returns, COR, refused COR) [2 Positions – Entry Detail Record, Corporate Entry Detail Record – Optional (ACK, ADV, ARC, ATX, BOC, CCD, CIE, CTX, DNE, MTE, POP, PPD, RCK, XCK, Returns, dishonored Returns, contested dishonored Returns, COR, refused COR)] This field in the Entry Detail Record allows ODFIs to include codes, of significance to them, to enable specialized handling of the Entry. There is no standardized interpretation for the value of this field. It can either be a single two-character code, or two distinct one-character codes, according to the needs of the ODFI and/or Originator involved. This field must be returned intact for any returned Entry. CCD, CTX: When an Acknowledgment Entry is requested by an Originator, this field contains “AK”. Payment Type Code: 2 Positions – Entry Detail Record – Required (WEB, Returns, dishonored Returns, contested dishonored Returns) [2 Positions – Entry Detail Record – Required (TEL, WEB, Returns, dishonored Returns, contested dishonored Returns)] This field is used to indicate whether a WEB Entry is a recurring or Single-Entry payment. For a recurring WEB Entry, this field must contain the value “R.” For a Single-Entry WEB Entry, this field must contain the value “S.” [This field is used to indicate whether a TEL Entry or a WEB Entry is a recurring or Single-Entry payment. For a recurring TEL or WEB Entry, this field must contain the value “R.” For a Single-Entry TEL Entry, this field must either contain the value “S” or be space-filled. For a Single-Entry WEB Entry, this field must contain the value “S.” ] Standard Entry Class: 3 Positions – Company/Batch Header – Mandatory (all batches) This field contains a three-character code used to identify various types of Entries.

ACK: ACH Payment Acknowledgment - The code that identifies a Non-Monetary Entry initiated by an RDFI to provide an acknowledgment of receipt by the RDFI of a corporate credit payment originated using the CCD format.


Page 34

ADV: Automated Accounting Advice - The code that identifies a Non-Monetary Entry that is used by an ACH Operator to provide accounting information regarding an Entry to Participating DFIs in machine readable format. An Automated Accounting Advice is an optional service provided by ACH Operators and must be requested by a DFI desiring this service. ARC: Accounts Receivable Entry – The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account based on an Eligible Source Document provided to the Originator by the Receiver via the U.S. mail or at a dropbox location. ATX: Financial EDI Acknowledgment - The code that identifies a Non-Monetary Entry initiated by an RDFI to provide an acknowledgment of receipt by the RDFI of a corporate credit payment originated using the CTX format. BOC: Back Office Conversion Entry – The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account 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. CCD: Corporate Credit or Debit Entry - The code that identifies an Entry initiated by an Organization to transfer funds to or from an account of that Organization or another Organization. CIE: Customer Initiated Entry - The code that identifies a credit Entry initiated by or on behalf of the holder of a Consumer Account to transfer funds to the account of the Receiver. COR: Notification of Change or Refused Notification of Change - The code that identifies a Non-Monetary Entry Transmitted by (1) an RDFI for the purpose of identifying incorrect information contained within an Entry and providing correct data in the precise format to be used on future Entries, or (2) an ODFI to refuse a misrouted NOC or an NOC that contains incorrect information. CTX: Corporate Trade Exchange - The code that identifies an Entry initiated by an Organization to transfer funds to or from the account of that Organization or another Organization that permits the inclusion of payment related remittance information in ANSI or UN/EDIFACT syntax. DNE: Death Notification Entry - The code that identifies a Non-Monetary Entry initiated by an agency of the Federal Government of the United States to notify an RDFI of the death of a Receiver. ENR: Automated Enrollment Entry - The code that identifies a Non-Monetary Entry initiated by a Participating DFI to an agency of the Federal Government of the United States on behalf, and at the request, of an account holder at the Participating DFI to enroll in a service that will enable Entries to such Person’s account at the Participating DFI. IAT: International ACH Transaction - The code that identifies an Entry that is part of a payment transaction involving a Financial Agency’s office that is not located in the territorial jurisdiction of the United States. An office of a Financial Agency is involved in the payment transaction if it (1) holds an account that is credited or debited as part of the payment transaction, (2) receives payment directly from a Person or makes payment directly to a Person as part of the payment transaction, or (3) serves as an intermediary in the settlement of any part of the payment transaction.


Page 35

MTE: Machine Transfer Entry - The code that identifies Entries initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds to or from a Consumer Account maintained with an RDFI, i.e., an ATM cash deposit or withdrawal. POP: Point-of-Purchase Entry - The code that identifies a Single Entry debit initiated by an Originator to the Receiver’s account based on an Eligible Source Document provided to the Originator by the Receiver at the point-of-purchase or manned bill payment location to transfer funds from the Receiver’s account. POS: Point of Sale Entry - The code that identifies a debit Entry initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds from a Consumer Account of the Receiver to pay an obligation incurred in a point-of-sale transaction, or to effect a point-of-sale terminal cash withdrawal. PPD: Prearranged Payment and Deposit Entry - The code that identifies an Entry initiated by an Organization based on a standing or a Single Entry authorization from a Receiver to transfer funds to or from a Consumer Account of the Receiver. RCK: Re-presented Check Entry - The code that identifies a Single Entry debit constituting a presentment notice of an item eligible under Article Two, Subsection 2.5.13.3 (RCK Eligible Items). An RCK Entry is an item as defined by Revised Article 4 of the Uniform Commercial Code (1990 Official Text) only for the limited purposes of presentment as set forth in Article 4-110(c) and notice of dishonor as set forth in Article 4-301(a)(2). SHR: Shared Network Transaction - The code that identifies a debit Entry initiated at an “Electronic terminal,” as defined in Regulation E, to transfer funds from a Consumer Account of the Receiver to pay an obligation incurred in a point-of-sale transaction, or to effect a point-of-sale terminal cash withdrawal. SHR Entries are initiated in a shared network where the ODFI and RDFI have an agreement in addition to these Rules to process such Entries. TEL: Telephone-Initiated Entry - The code that identifies a Single-Entry debit initiated by an Originator pursuant to an oral authorization obtained over the telephone to transfer funds from a Consumer Account of the Receiver. [The code that identifies a debit initiated by an Originator pursuant to an oral authorization obtained over the telephone to transfer funds from a Consumer Account of the Receiver.] TRC: Check Truncation Entry - The code that identifies a debit Entry initiated pursuant to a Check Truncation Program that permits the Truncation of a single Check drawn on the paying bank. TRX: Check Truncation Entries Exchange - The code that identifies a debit Entry initiated based on a Check Truncation Program that permits the Truncation of multiple Checks drawn on the same paying bank. WEB: Internet-Initiated/Mobile Entry - The code that identifies a debit Entry initiated by an Originator to a Consumer Account of the Receiver based on (1) an authorization that is communicated, other than by an oral communication, from the Receiver to the Originator via the Internet or a Wireless Network, or (2) any form of authorization if the Receiver’s instruction for the initiation of the individual debit Entry is designed by the Originator to be communicated, other than by an oral communication, to the Originator via a Wireless Network. XCK: Destroyed Check Entry - The code that identifies a debit Entry initiated in the event an item eligible under Article Two, subsection 2.5.18.2 (XCK Eligible Items) is


Page 36

contained within a cash letter that is lost, destroyed, or otherwise unavailable to and cannot be obtained by the ODFI.

APPENDIX FOUR – REURN ENTRIES

Part 4.2 – Table of Return Reason Codes

[Effective September 16, 2011, the “Notes” discussion for Return Reason Code R07 (Authorization Revoked by Customer) will be revised to remove TEL and WEB from the restrictions on the use of this return code. (Please refer to the Table of Return Reason Codes that follows.)]


Page 37

SUBSECTION 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 ELEMENT NAME

RECORD TYPE CODE

TRANSACTION CODE

RECEIVING DFI IDENTIFICATION

CHECK DIGIT

DFI ACCOUNT NUMBER

AMOUNT

INDIVIDUAL IDENTIFICATION

NUMBER

INDIVIDUAL NAME

DISCRETION-ARY DATA [PAYMENT

TYPE CODE]

ADDENDA RECORD

INDICATOR

TRACE NUMBER

Field Inclusion Requirement

M

M

M

M

R

M

O

M

O 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

2011 OPERATING RULES

APPENDIX FOUR – Retu rn En t r ies

CO

DE

TITL

E D

ESC

RIP

TIO

N

INIT

IATE

D

BY

RET

UR

NTY

PE

AC

CO

UN

TTY

PE

TIM

EFR

AM

E

WR

ITTE

N

STAT

EMEN

T R

EQU

IRED

CR

OSS

REF

EREN

CE

NO

TES

R07

Auth

oriz

atio

n Re

voke

d by

Cu

stom

er

The

RD

FI’s

cus

tom

er (t

he

Rec

eive

r) re

voke

d th

e au

thor

izat

ion

prev

ious

ly

prov

ided

to th

e O

rigin

ator

for

this

deb

it E

ntry

.

RD

FI

Ext

ende

d R

etur

n C

onsu

mer

**

60

Cal

enda

r Day

s

Yes

Arti

cle

Thre

e, S

ectio

n 3.

13

- RD

FI R

ight

to T

rans

mit

E

xten

ded

Ret

urn

Ent

ries.

Arti

cle

Thre

e, S

ubse

ctio

n 3.

12.1

- U

naut

horiz

ed D

ebit

Ent

ry

This

Ret

urn

Rea

son

Cod

e m

ay

not b

e us

ed fo

r PO

P E

ntrie

s,

Sin

gle-

Ent

ry W

EB

Ent

ries,

or

TEL

Ent

ries.

[Thi

s Re

turn

Rea

son

Code

[T

his

Retu

rn R

easo

n Co

de

may

not

be

used

for P

OP

may

not

be

used

for P

OP

Entri

es.]

Entri

es.]

R08

Paym

ent

Stop

ped

The

Rec

eive

r has

pla

ced

a st

op p

aym

ent o

rder

on

this

de

bit E

ntry

.

RD

FI

Ret

urn

Con

sum

er o

r N

on-C

onsu

mer

*

2 B

anki

ng D

ays

No

Arti

cle

Thre

e, S

ectio

n 3.

7 - R

DFI

Obl

igat

ion

to S

top

Pay

men

t.

A st

op p

aym

ent o

rder

may

be

pl

aced

on

one

or m

ore

debi

t E

ntrie

s.

R09

Unco

llect

ed

Fund

s A

suffi

cien

t led

ger b

alan

ce

exis

ts to

sat

isfy

the

dolla

r va

lue

of th

e tra

nsac

tion,

bu

t the

ava

ilabl

e ba

lanc

e is

be

low

the

dolla

r val

ue o

f the

de

bit E

ntry

.

RD

FI

Ret

urn

Con

sum

er o

r N

on-C

onsu

mer

*

2 B

anki

ng D

ays

No

Arti

cle

Thre

e, S

ectio

n 3.

8 - R

DFI

’s R

ight

to T

rans

mit

Ret

urn

Ent

ries.

R10

Cust

omer

Ad

vise

s No

t Au

thor

ized

, Im

prop

er, o

r In

elig

ible

The

RD

FI h

as b

een

notif

ied

by th

e R

ecei

ver t

hat t

he E

ntry

is

una

utho

rized

, im

prop

er, o

r in

elig

ible

.

RD

FI

Ext

ende

d R

etur

n C

onsu

mer

; for

A

RC

, BO

C, I

AT,

or P

OP,

Ent

ries

may

als

o be

a

Non

-Con

sum

er.

See

not

e fo

r ad

ditio

nal

exce

ptio

ns.

** 6

0 C

alen

dar D

ays

Yes

Arti

cle

Thre

e, S

ubse

ctio

n 3.

12.1

- U

naut

horiz

ed D

ebit

Ent

ry.

Arti

cle

Thre

e, S

ubse

ctio

n 3.

12.2

- Im

prop

er A

RC

, BO

C,

PO

P, a

nd R

CK

Deb

it E

ntrie

s.

Arti

cle

Thre

e, S

ubse

ctio

n 3.

1.3

- RD

FI M

ay R

ely

on S

tand

ard

Ent

ry C

lass

Cod

es.

Arti

cle

Thre

e, S

ubse

ctio

n 3.

4.1.

2 R

ule

Exc

eptio

n fo

r C

CD

or C

TX E

ntrie

s to

C

onsu

mer

Acc

ount

s.

Arti

cle

Thre

e, S

ectio

n 3.

13

- RD

FI R

ight

to T

rans

mit

Ext

ende

d R

etur

n E

ntrie

s.

May

be

used

for a

ny E

ntry

ex

cept

CC

D o

r CTX

Ent

ries

For C

CD

or C

TX E

ntrie

s to

C

onsu

mer

Acc

ount

s, s

ee R

05.

For C

CD

or C

TX to

Non

-C

onsu

mer

Acc

ount

s, s

ee R

29.

May

als

o be

use

d to

retu

rn a

n un

auth

oriz

ed d

ebit

Ent

ry to

a

non-

cons

umer

acc

ount

if th

e de

bit E

ntry

con

tain

s a

cons

umer

S

EC

Cod

e.

* E

ach R

eturn

Entr

y m

ust

be

rece

ived

by

the

RD

FI’s A

CH

Oper

ator

by

its

dep

osi

t dea

dline

for

the

Ret

urn

Entr

y to

be

mad

e av

aila

ble

to the

OD

FI n

o lat

er than

the

open

ing

of

busi

nes

s on the

seco

nd

Ban

kin

g D

ay follow

ing

the

Settle

men

t D

ate

of

the

ori

ginal

Entr

y. **

Eac

h R

eturn

Entr

y m

ust

be

rece

ived

by

the

RD

FI’s A

CH

Oper

ator

by

its

dep

osi

t dea

dline

for

the

Ret

urn

Entr

y to

be

mad

e av

aila

ble

to the

OD

FI

no lat

er than

the

open

ing

of

busi

nes

s on the

Ban

kin

g D

ay follow

ing

the

sixt

ieth

cal

endar

day

follow

ing

the

Settle

men

t D

ate

of

the

ori

ginal

Entr

y.

PAR

T 4.

2 Ta

ble

of R

etur

n R

easo

n C

odes

(co

ntin

ued)

Documents

NACHA Operating Rules ￚ - Goodwin/media/59E1B8A833E54C7082D2...On March 18, 2011, an amendment to the NACHA Operating Rules will become effective that eliminates the requirement