Home / Industry News / RFC Enhancements

Request for Comment
Enhancements to ACH Applications – ARC, BOC, POP, TEL, XCK; Collection of Service Fees

Supporting Documents:

Executive Summary and Rules Description
NACHA requests comment on a proposal to amend the NACHA Operating Rules entitled "Enhancements to ACH Applications." Comments are due by August 6, 2010.

Part I: Proposal Brief
This proposal ("Rule") would amend the NACHA Operating Rules to make enhancements to, or lower barriers to the use of, several existing ACH applications. The Rule would encourage greater use of these ACH applications by removing barriers to their use, and by updating some existing ACH applications to accommodate recent industry developments and regulatory changes. In addition, the Rule contributes to two overarching objectives – 1) to better align the Rules, whenever possible, with existing regulations such as Regulation E, and 2) to provide alternatives within the ACH Network to the legitimate uses of remotely created checks.

NACHA anticipates that the Rule would make use of the ACH Network more appealing to Originators for a variety of payments. This Rule would:

Expand the scope of the TEL application to permit its use for recurring consumer transactions;
Eliminate the requirement that Originators have opt-out procedures for ARC and BOC transactions;
Increase the dollar limit for ARC, BOC and POP transactions;
Address authorization and identification requirements to facilitate the collection of service fees related to certain checks and ACH debits that have been returned unpaid;
Expand the scope of the XCK application to permit its use for certain damaged checks that cannot be imaged, or other check images that cannot be processed.

The Rule is proposed to become effective on March 18, 2011.

Part II: Justification for the Proposal

A. Recurring TEL Transactions

The 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 by mail (processes that reduce electronic payment enrollment rates), or use a different method of payment, such as remotely created checks ("RCC").

This Rule would expand the scope of the TEL application to permit its use for recurring debits. An Originator using TEL for recurring debits would have to ensure that the oral authorization complies with Regulation E's writing and signature requirements for preauthorized transfers, which can be satisfied by compliance with the Electronic Signatures in Global and National Commerce Act (e-Sign Act). The rules regarding the use of TEL for single entries would not change.

Compliance with Regulation E and the e-Sign Act

Regulation E permits preauthorized (recurring) electronic fund transfers from a consumer's account only if the transactions are "authorized by the consumer … in writing" and "a copy of such authorization [is] provided to the consumer when made."¹ As mentioned previously, until 2006, the Commentary specifically precluded the use of a recorded telephone conversation in order to satisfy the requirement for written authorization.² In 2006, however, the Federal Reserve Board amended the Commentary ³ to eliminate that restriction in response to industry assertions that the preclusion of recorded telephone calls was inconsistent with the Electronic Signatures in Global and National Commerce Act ("e-Sign Act"). Thus, Regulation E now permits preauthorized transfers from a consumer account as long as the form of the preauthorization satisfies the e-Sign Act's requirements for treatment of an electronic communication as the equivalent of a writing.

With respect 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 e-Sign Act, which provides for legal equivalence of electronic records and electronic signatures with their physical counterparts. Thus, an Originator using recurring TEL would have to ensure that its authorizations, including, for example, the use of a recorded telephone conversation, are in compliance with the e-Sign Act.

Use of R07 for TEL and WEB Entries

The Rule proposes to modify R07 to allow its use for TEL Entries because it would now be possible for there to be 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 many 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 also proposes to eliminate this limitation in the use of R07.

B. Elimination of the Opt-Out Requirement for ARC and BOC

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.

The Rule would remove the requirements for ARC and BOC Entries that Originators must have procedures to allow Receivers to opt-out of check conversion. Originators that wish to allow their customers to opt-out of ARC and BOC transactions could continue to do so. 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.

C. Dollar Limits on ARC, BOC and POP Entries

The Rules contain a dollar limit of $25,000 for ARC, BOC and POP check conversion transactions. The limit was originally established to 1) minimize return risk to the ODFI and Originator for "checks" which now could be returned for up to 60 days, 2) exclude checks that might be more appropriately collected in a wholesale environment, and 3) allow Paying Banks to continue to inspect signatures and security features of large-dollar checks.

More recently, some Originators have reported to NACHA that the current $25,000 dollar limit restricts the use of check conversion in a retail environment and requires Originators to have alternative clearing procedures in place for a small volume of checks. Card issuers, in particular, have reported that they receive a small volume of checks drawn on consumer or small business accounts (including sole proprietorships and partnerships) as payment for monthly balances that exceed the $25,000 limit. Raising the dollar limit would eliminate the need for these Originators to clear these payments separately as checks or images.

The Rule would increase the dollar limit for ARC, BOC and POP Entries to $50,000. This higher limit reflects the results of a survey by NACHA's Electronic Check Council that balances the business case and operational improvements for some Originators with a continued desire to mitigate risk.

There was also some support in the survey, however, for removing the dollar cap entirely. ARC, BOC and POP Entries have a relatively low risk profile. In 2009, fewer than two hundred thousand ARC, BOC and POP Entries, combined, were returned using 60-day return reason codes, out of approximately 3 billion forward entries. Additionally, the Rules would continue to prohibit the conversion of checks with an Auxiliary On-Us field, which has proven effective in preventing the conversion of most checks drawn on corporate accounts.

An ODFI also would not be required to allow higher-dollar transactions. An ODFI could always choose to restrict ARC, BOC and/or POP Entries to the existing $25,000 dollar amount or some other lower dollar amount for all of their Originators, or to limit the dollar amount on an Originator-by-Originator basis. An ODFI that has no internal business case for increasing the dollar amount (e.g., not applicable to any of its Originators, low return-on-investment for small volume of transactions) would not be required to do so.

In addition to comments about the proposed $50,000 dollar cap, NACHA specifically requests comment on whether ARC, BOC and POP Entries should have any dollar limits at all.

D. Collection of Service Fees

Many merchants and billers assess a service fee to help recover costs associated with the collection of payments returned unpaid, including due to reasons of insufficient or uncollected funds. Service fees are often governed by state law. Currently, 42 states and the District of Columbia explicitly allow for the collection of a service fee when a check is dishonored. The maximum amount of the service 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 service fee will be assessed if the item is returned unpaid.

Currently, the Rules do not differentiate an ACH debit for the collection of a service fee from any other 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 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 service 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 service 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. This revision to Regulation E made it clear that the Rules were more restrictive than the regulation.

These differing requirements create challenges for some businesses, particularly with respect to checks, check conversion (ARC, BOC and POP) and check truncation transactions (RCK), where the current written authorization requirements for service fees can present a burden to both merchants/billers and customers alike. In order to use the ACH Network to collect a service 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, Originators and potential Originators of ACH transactions often use other payment methods, such as RCCs, to collect service fees.

To the extent that an Originator can use the ACH Network today to collect service 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 service 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 service fee and in reconciling his account, which can then lead to customer service contacts for RDFIs.

This Rule proposes to specifically address authorization and transaction identification requirements for ACH debits used to collect service fees. Overall, the approach to the collection of service fees via the ACH Network would align the Rules with Regulation E, and would lower barriers for a legitimate use of the ACH Network by Originators, enable an alternative to the use of RCCs. The Rule would also minimize customer confusion by defining clear standards for the authorization and identification of ACH debits used to collect service fees.

Authorization of a Service Fee Entry

This Rule creates a new debit Entry type - a Service Fee Entry - that would be used only for the purpose of collecting service fees for 1) certain ACH Entries that are returned unpaid, or 2) other qualifying checks that are returned unpaid. The Rule would explicitly define authorization and formatting requirements for an ACH debit used to collect a service fee from a consumer ⁴ when an underlying check or ACH debit is returned unpaid.

When the underlying transaction is a check, the Rule would allow authorization of a Service Fee Entry by providing notice that conforms to the requirements of Regulation E. When the underlying transaction is an ACH debit, the Rule would allow the authorization of a Service Fee Entry to be obtained at the same time and in the same manner as the authorization for the underlying ACH debit. If the authorization of a Service Fee Entry is not obtained at the same time and the same manner as the underlying ACH debit, authorization can be obtained in a manner permissible under the Rules for the SEC Code used (see discussion below).

The following are examples of how Originators can obtain authorization for a Service Fee Entry under the proposed Rule:

A merchant accepts a check from a customer and does not convert the check to ACH (i.e., processes as a check). The merchant can obtain authorization for a Service Fee Entry by posting notice in conformance with Regulation E. If the check is returned unpaid, the merchant can originate a Service Fee Entry.
A merchant accepts a check from a consumer and converts it to a BOC Entry. Authorization for the BOC Entry was obtained in conformance with Regulation E and the NACHA Rules by posting a conspicuous notice with clear and readily understandable terms, and then obtaining the customer's signed check. The merchant can obtain authorization for a Service 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 unpaid, the merchant can originate a Service Fee Entry.
A billing company obtains a written, signed authorization to enroll a customer in monthly Direct Payment, which is collected via a monthly PPD debit. Under the Rule, an Originator can obtain authorization for a Service Fee Entry via the same written, signed authorization, as long as all the requirements for authorization of a PPD Entry are met (e.g., readily identifiable as an authorization, clear and readily understandable terms, etc.). If a PPD debit is returned unpaid, the billing company can originate a Service Fee Entry. While an Originator could use this approach under the current Rules, the proposed Rule would make this explicit.

SEC Codes for a Service Fee Entry

The Rule would require the use of SEC Codes for Service Fee Entries in the following ways:

If the Service Fee Entry is related to an underlying check transaction, and authorization is obtained in conformance with Regulation E, the Service Fee Entry would use a check conversion SEC Code. In example number 1 above, the Service Fee Entry would use the BOC code.⁶
If the authorization for the Service Fee Entry is obtained at the same time and in the same manner as an underlying ACH debit, the Service Fee Entry would use the same SEC Code as the underlying ACH debit. In example 2 above, the Service Fee Entry would use the BOC code, because the underlying transaction was a BOC Entry. In example number 3 above, the Service Fee Entry would use the PPD code, because the underlying transaction was a PPD Entry.
If the authorization for the Service Fee Entry is obtained separately at a different time or manner from the underlying ACH debit, the Service Fee Entry would use the SEC Code that is the most appropriate for the manner in which authorization is obtained. If the authorization for the Service Fee Entry is obtained via the Internet, it would be coded as a WEB; if obtained orally over the phone, it would use TEL, etc.

The rationale for using SEC Codes in these ways is that it:

Maintains a close approximation to how SEC Codes are used today – related to the manner of authorization;
Allows service fees related to checks or check conversion Entries to carry the check serial number (or a variation of the check serial number – see discussion below); and those that are not related to checks or check conversions will have no such information to carry.

Identification of a Service Fee Entry

To enable Receivers to identify Service Fee Entries, the Rule would require Originators to include the exact letters "SERVICEFEE" 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 (see below). This method of identification is the same as for other specific types of ACH Entries such as reversals, reclamations, and destroyed checks.

Number and Timing of Service Fees

The Rule would allow an Originator to originate a single Service Fee Entry in relation to an underlying transaction, regardless of the number of times the underlying transaction is returned unpaid. For example, an ACH transaction can be returned for insufficient funds as many as three times, but the Originator would be able to initiate only one service fee.

A Service Fee Entry that is itself returned unpaid may be re-initiated in accordance with the rules on re-initiation. A Service Fee Entry, however, may not be originated in relation to an underlying transaction that is a Service Fee Entry (i.e., no service fee on a service fee).

Because some merchants/Originators attempt to time check re-presentments, ACH re-initiations, and service fees to specific days when they predict that funds are most likely to be available, the Rule does not prescribe any specific timing of the Service Fee Entry in relation to the underlying transaction. The Rule, however, does state that the Service Fee Entry must have a Settlement Date that is no later than 90 days after the Settlement Date of the ACH Return Entry or the receipt of the return of the underlying check transaction.

E. Expanded Use of the Destroyed Check Entry (XCK) Application

For some time, the financial industry has been assessing additional means for electronically processing and collecting physically damaged checks for which an image cannot be made, or other check images for which the image cannot be processed. While the percentage of such transactions is low, the relative impact on processing and clearing costs from such transactions can be significant. On a per-item basis, clearing times and costs of collecting these items through a drastically reduced physical check clearing infrastructure have risen substantially and will continue to do so. If even a small or fractional percentage of the billions of checks written each year result in checks that must be collected through physical carrier envelopes because they are damaged or produce poor quality images, then this would still represent substantial volume.

This Rule would expand the use of the existing Destroyed Check Entry (XCK) application to permit the clearing, through the ACH Network, of certain items that cannot be imaged or that result in 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, but in each case contain sufficient information to process as an ACH Entry.

The expansion of the XCK application in this manner would provide financial institutions with an additional, optional clearing mechanism using an established ACH format. Table 1 presents the findings from a 2009 industry survey conducted by NACHA's Electronic Check Council ⁷ and shows the types of problems with checks regarded as non-imageable that are proposed to be included in an expanded use of XCK.

Table 1
Type of Problem with Check	% of Respondents Identifying This Type of Non-imageable Item as "High Priority"	% of Respondents Agreeing This Type of Item Should be Defined as Non-imageable Item
Checks that create images that cannot be read (in whole or in part)	75%	96%
Checks missing part of the MICR line but which can be repaired sufficiently to create an ACH Entry	70%	71%
Checks that create images that do not pass standard or agreed-upon quality tests	70%	79%
Partial, mutilated or torn checks (other than MICR line)	58%	92%
Checks that create images that have invalid TIFF tags	27%	62%

The key benefits of expanding XCK include a substantially lower per-item cost than existing collection alternatives, the ability to reach all financial institutions, and minimal systems and procedural changes.

The use of XCK for the purpose of clearing these types of items would be optional for both ODFIs (Collecting Banks) and RDFIs (Paying Banks). ODFIs would not be obligated to originate such Entries, and RDFIs would not be obligated to accept such Entries. RDFIs would retain their right to return XCK Entries for any reason for up to 60 days following settlement. 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, would be retained.

Part III: Impact of the Proposed Rule

Benefits of the Proposed Rule

NACHA anticipates that the Rule would make use of the ACH Network more appealing to Originators for a variety of payments. Originators and ODFIs would be able to: 1) establish recurring payments with new customers during an initial telephone session; 2) eliminate the need to retain alternate processing methods for the small volume of checks for which customers opt-out of ARC and BOC check conversion; 3) eliminate the need to retain alternate processing methods for the small volume of checks that are between $25,000 and $50,000 that might otherwise be processed as ARC, BOC or POP transactions; and 4) have an explicit and streamlined method for collecting service fees. Collecting banks would also be able to use the XCK application to collect a new category of damaged checks and unprocessable check images.

The Rule also brings the NACHA Rules into better alignment with Regulation E. Recent changes to Regulation E have eliminated the prohibition on oral authorization of preauthorized debits, and allow notice for the collection of service fees by electronic fund transfer. Alignment with Regulation E has been an overarching objective of NACHA rulemaking for some time. Other examples include stop payments (effective March 19, 2010), and the timeframes associated with dispute resolution and returns (Request for Comment issued September 1, 2009).

Another benefit of the Rule is better industry risk management by offering Originators an alternative to RCCs. The Rule proposes to allow or expand the use of the ACH Network for two legitimate business applications that it does not serve well today – recurring telephone payments, and the collection of service fees. Merchants and billers that would like to use the ACH Network for these payments cannot do so efficiently, and so instead use other payment methods. In these two business applications, merchants and billers often use RCCs.

According to NACHA's Risk Management Advisory Group (RMAG), RCCs are "vulnerable to fraud because they do not bear a readily verifiable indication of authorization," and because they cannot be distinctly identified and tracked through the collection system.⁸ In Canada, the Canadian Payments Association has banned the use of RCCs.⁹ In the United States, the state attorneys general have called for RCCs to be eliminated in favor of electronic funds transfers.¹⁰

RMAG concludes that: "(1) ACH transactions offer a payment choice where the safeguards to Receivers outweigh the conveniences that RCCs currently offer to Payees and (2) with changes to the Rules, the ACH Network can offer greater convenience with less risk for a range of payment applications."

Costs to Comply with the Proposal

Actual costs for implementation of this proposal have not yet been determined. Information related to costs is requested through responses to the accompanying ACH Participant Survey.

NACHA anticipates that costs would be borne by ACH Network participants specific to implementation of the following aspects of the Rule:

Recurring TEL

Originators that want to use recurring TEL would have 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 would have to accommodate an indicator in the TEL Entry Detail Record field currently used for Discretionary Data;
ODFIs and RDFIs would have to enable the use of Return Reason Code R07 with TEL Entries.

ARC and BOC Opt-Out

Existing ARC and BOC Originators that do not want to continue to offer opt-out may want to modify authorization notices, and also may want to notify existing customers about any changes to their check conversion policies.
RDFIs may experience an initial increase in customer service contacts from customers who had previously opted-out, or would like to opt-out. Experience suggests that any customer service impact would initially be modest, and then diminish over time.

ARC, BOC and POP Dollar Limits

ACH Operators would need to update edits on dollar limits.
ACH software providers may need to modify built-in dollar limits.
ODFIs and RDFIs may need to modify ACH software and test any such changes.
ODFIs and RDFIs may want to assess risk management tools and processes for further scrutiny of relatively higher dollar transactions.

Service Fees

Originators that want to use the ACH Network to collect service fees would need to implement processes, including authorizations and/or notices, that are appropriate to their businesses and practices.
Originators, ODFIs and their service providers would need to be able to use appropriate SEC Codes, and would need to be able to properly populate the Check Serial Number field when appropriate.
RDFIs would need to be able to provide the "SERVICEFEE" descriptor contained in the Company Entry Description field and, for check conversion SEC codes, the contents of the Check Serial Number field to customers. The contents of these fields are already required under the Rules to be provided to customers.
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.

XCK

ODFIs that want to use this XCK application would need to be able to populate the ACH formats from captured MICR information.
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.

Part IV: Additional Issues

A. Recurring TEL

Compliance with e-Sign Act

Authorizations for recurring TEL Entries would need to meet the requirements of Regulation E, 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. While the NACHA membership can approve a rule that refers to compliance with the e-Sign Act, NACHA would not be in a position to provide certainty to Originators on how to comply with the e-Sign Act. Originators using recurring TEL would need to be able to determine their own compliance with the e-Sign Act.

Indicator for Recurring or Single-Entry TEL

The Rule would change field 9 of a TEL Entry Detail Record from Discretionary Data to Payment Type Code, and require that the field contain either an "R" for recurring or an "S" for Single-Entry. This is identical to how the field is used for WEB Entries to signify recurring or Single-Entry WEB. An alternative approach, however, is to allow this field to contain an "R", an "S", or to remain empty. While this would be inconsistent with WEB, one of the principles of this Rule proposal is to not change the Rules for Single-Entry TEL, and to require no changes of Originators using Single-Entry TEL. Such Originators would have the option to leave this field empty, which may save on costs and effort required to reprogram the field. Originators that use both recurring and Single-Entry TEL and WEB would have the option to use the field consistently for both SEC Codes. NACHA specifically requests comment on the pros and cons of these alternative approaches.

B. Collection of Service Fees

Use of SEC Codes for Service Fees

There are alternatives to the Rule's approach for the use of SEC Codes (see section "SEC Codes for a Service Fee Entry" above, Page 7). The Rule could establish a new SEC Code that would be used expressly for Service Fee Entries; or the Rule could specify that a single, existing SEC Code (such as PPD) be used for all Service Fee Entries, regardless of the manner of authorization or the nature of the underlying transaction.

Each of these alternate approaches, however, has drawbacks. Establishing a new SEC Code requires the industry to build and test new software and processes. Using a single, existing SEC Code does not require a "build," but the SEC Code loses some of the relationship to the method of authorization, and may not be able to accommodate all the information needed to flow with the transaction (see section "Provision of Check Serial Numbers" below).

Return Reasons

Regulation E's notice equals authorization approach applies to "the return of an electronic fund transfer or a check that is unpaid, including due to insufficient or uncollected funds." That is, insufficient or uncollected funds are examples of return reasons for which a merchant/Originator may collect a service fee, but are not the exclusive reasons.

NACHA specifically requests comment on how the application of service fees related to return reasons translates into the ACH Network environment. Within the ACH Network, returns for insufficient funds and uncollected funds are designated by return codes R01 and R09, respectively. Should Service Fee Entries related to underlying ACH debits be limited to R01 and R09 returns, or are there other return reasons that should specifically be included, such as stop payment? Conversely, should service fees be broadly allowable, with only specific return reasons, such as unauthorized, excluded? Should the same limitation(s) be placed on service fees when the underlying transaction is a check? NACHA also requests comment on whether any such limitations would limit the appeal to Originators of using the ACH Network to collect service fees.

Provision of Check Serial Numbers

Service Fee Entries bearing the SEC Codes ARC, BOC, POP and RCK will need to include appropriate information in the Check Serial Number field of the Entry Detail record. One approach would be to simply use the same check serial number as the underlying transaction. This would provide additional identification to Receivers on their statements that a service fee is related to a specific check number.

The provision of the check serial number in a Service Fee Entry, however, could impact RDFIs' systems that use check serial numbers in particular ways. For example, RDFIs might identify duplicate payments using check serial numbers. Stop payment systems might also make use of check serial numbers.

Variations on the approach would include the word "FEE" in addition to, or instead of, the check serial number, such as "FEE 1234", "1234 FEE", "1234NSF", or simply "FEE". NACHA requests comments on the ability of DFI's systems to handle such information.

Part V: Rules Framework

Recurring TEL Entries

This Rule would 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. It would also expand the specific authorization language to address authorization requirements for recurring TEL Entries in conformance to the requirements of Regulation E.

The Entry Detail Record format for TEL Entries would be modified to replace the 2-character Discretionary Data field with a new Payment Type Code, within which an indicator "R" for recurring or "S" for single entry would be placed to identify whether the TEL Entry is a one-time transaction or a recurring payment. This is identical to the use of the Payment Type Code field for WEB Entries.

The Return Reason Code R07 would be modified to allow its use to return TEL and WEB Entries.

Elimination of the Opt Out Requirement for ARC and BOC

This proposal would revise the Rules to remove an Originator's obligation to allow a Receiver to opt out of check conversion. An Originator may, however, continue to allow customers to opt out at its discretion.

Dollar Limits on ARC and BOC Entries

The Rule would replace the existing $25,000 limit for ARC, BOC and POP Entries with a $50,000 limit.

Authorization and Formatting Requirements for Service Fees

This Rule would define and establish a Service Fee Entry as a specific type of ACH Entry, and establish the parameters for its use, authorization, formatting, and transaction identification. The Rule includes a new warranty specific to a Service Fee Entry.

XCK Eligibility

This Rule would revise the definition of, and general rule for, Destroyed Check Entries to allow their use to collect certain damaged checks for which processable images cannot be made, or for certain check images that are unprocessable.

The XCK eligibility requirements would be expanded to incorporate the following as examples, but not as an exhaustive list, 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.

Part VI: Implementation

This proposal recommends an effective date of March 18, 2011.

Part VII: Technical Summary

The following changes to the Rules language represent modifications to the 2011 NACHA Operating Rules, as approved through the rules simplification process, that become effective on January 1, 2011:

Article Two, subsections 2.5.1.2 (Authorization for 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.
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) – revises authorization requirements for TEL Entries to incorporate requirements for recurring 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 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.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.
Article Two, section 2.14 (Service Fee Entries) – adds a new section to the rules specific to the collection of service fees via the ACH Network; included within this new section are specific subsections addressing the general rule on service fee entries, authorization requirements, notification and disclosure, formatting, applicability of other rules on service fees, and additional ODFI warranties. Sections in Article Two following the new section 2.14 would be renumbered.
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.
- Section 8.32 (Eligible Source Document) – modifies the definition of Eligible Source Document for ARC, BOC, and POP Entries to increase the limit on dollar amount to $50,000.
- Section 8.83 (Service Fee) – adds Service Fee to the list of defined terms.
- Section 8.84 (Service Fee Entry) – adds Service Fee Entry to the list of defined terms. Definitions following Service Fee Entry would be renumbered.
- Section 8.89 (Telephone-Initiated Entry/TEL Entry/TEL) – revised the definition of Telephone-Initiated Entry to accommodate its use for recurring entries.
Appendix Two, Part 2.5 (Automatic Entry Detail Rejection Criteria) – revises the ACH Operator Return Reason Code R19 (Amount Field Error) to increase the dollar limit for ARC, BOC, and POP Entries to $50,000.
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.1 (Field Inclusion Requirements) – revises the following field descriptions/inclusion requirements:
- Company/Entry Description – requires a specific descriptive statement when the batch contains Service Fee Entries;
- 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 – (1) revises the description of the TEL SEC Code to incorporate recurring transactions; and (2) revises the description of the XCK SEC Code to eliminate redundant language defined under eligibility criteria.

1 15 U.S.C. §1693e(a); see also 12 C.F.R. § 205.10(b). (back)

2 12 C.F.R. Part 205, Supp. I, Comment 10(b)-3 (2005) ("A tape recording of a telephone conversation with a consumer who agrees to preauthorized debits also does not constitute written authorization for purposes of this provision."). (back)

3 See 71 Fed. Reg. 1638 (Jan. 10, 2006). (back)

4 The Rule would also permit Service Fee Entries to non-consumers 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. (back)

5 The Rules always allow Originators to obtain a written, signed authorization for a consumer ACH debit, even in cases where the Rules also permit another method of authorization. Where a Service Fee Entry is allowed to be authorized by "notice = authorization," for example, an Originator could opt to obtain a written, signed authorization. (back)

6 The POP code would not be used in this scenario, because the POP format requires the inclusion of terminal information that is not relevant to the underlying check transaction. A variation on this scenario is that the Service Fee Entry is authorized by notice on a billing statement in relation to a check sent in the mail to pay a bill. In this scenario, the Service Fee Entry would use the ARC code. (back)

7 The ECC survey was distributed to the ECC and the NACHA family email lists, with directions to circulate among check, ACH and legal practitioners. (back)

8 Remotely Created Checks and ACH Transactions: Analyzing the Differentiators - A Risk Management White Paper; NACHA – The Electronic Payments Association; March 2010. (back)

9 "Prohibition of Tele-cheques in the Clearing and Settlement System - Policy Statement," Canadian Payments Association. (June 1, 2003) http://www.cdnpay.ca/news/tele.asp (back)

10 Comment to FRB Docket No. R-1226 (Proposed Amendment to Regulation CC/Remotely Created Checks), May 3, 2005, National Association of Attorneys General -
http://www.federalreserve.gov/SECRS/2005/May/20050512/R-1226/R-1226_264_1.pdf (back)

NACHA STAFF CONTACTS

Return comments to:
Maribel Bondoc, Manager, Network Rules
Fax: (703) 787-0996 E-mail: mbondoc@nacha.org

Questions:
Ian Macoy, Managing Director, Network Strategy and Outreach
Phone: (703) 561-3929
E-mail: imacoy@nacha.org

Cari Conahan, AAP, Senior Director, ACH Network Rules
Phone: (703) 561-3921
E-mail: cconahan@nacha.org

Request for Comment Enhancements to ACH Applications – ARC, BOC, POP, TEL, XCK; Collection of Service Fees

Request for Comment
Enhancements to ACH Applications – ARC, BOC, POP, TEL, XCK; Collection of Service Fees