nacha operating rules · 2018. 3. 22. · 2013 nacha operating rules and guidelines . may 1, 2013 ....

NOTICE OF AMENDMENTS

TO THE

2013 NACHA OPERATING RULES AND GUIDELINES

May 1, 2013

SUPPLEMENT #1-2013

NACHA Operating Rules

Effective Date: March 15, 2013

1. ODFI Warranties – Compliance with Foreign Payment System Rules

Effective Date: September 20, 2013

2. Originator Obligations with Respect to Notifications of Change for Single Entries 3. Stop Payments - Effective Period of Stop Payment for Non-Consumer Account

Effective Date: March 21, 2014

4. Identification of Additional Parties to an IAT Entry 5. Identification of Country Names Within IAT Entries

6. Person-to-Person Payments via ACH

Effective Date: September 19, 2014

7. Proof of Authorization for Non-Consumer Entries

Effective Date March 20, 2015

8. Dishonored Returns and Contested Dishonored Returns Related to an Unintended Credit to a Receiver

NACHA Operating Guidelines 1. General Rules

2. ODFI Risk Management

© 2013 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.

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

dfoli

Typewritten Text

2

SUPPLEMENT #1-2013 TO THE NACHA OPERATING RULES

Supplement #1-2013 to the NACHA Operating Rules

On March 7, 2013, NACHA’s Voting Membership approved eight amendments to the NACHA Operating Rules (Rules). The effective dates for these rule changes cover a two-year period between March 15, 2013 and March 20, 2015. The effective date for each specific change is indicated below.

This supplement provides ACH Network participants with a summary of the key components of each change, along with details regarding the technical changes to Rules language. To ensure compliance with the most current rules, this Supplement should be used in conjunction with the 2013 edition of the Rules.

3


ODFI Warranties – Compliance with Foreign Payment System Rules

(Approved March 7, 2013 – Effective March 15, 2013)

SUMMARYThis Rule revised the ODFI’s warranty of compliance with foreign payment system rules (for Outbound IAT Entries), narrowing its scope to focus only on authorization of the Entry when such authorization is required by the laws or payment system rules of the receiving country. The narrower warranty also limits the scope of the ODFI’s indemnity for breach of warranty.

KEY COMPONENTS OF RULE AMENDMENTODFI Warranty for Outbound IAT Entries - Compliance with Foreign Laws or Payment System Rules Regarding Authorization Effective March 15, 2013, ODFIs transmitting Outbound IAT Entries warrant only that they are in compliance with foreign laws or payment system rules regarding authorization of the Entry, if authorization is required. ODFIs presumably will pass this warranty to their Originators in order to confirm that Originators have obtained any authorization required for their Outbound IAT Entries.

Assumption of Risk by ODFI/OriginatorRegardless of this narrowing of the ODFI’s warranty, Gateways should not have to bear the risk that foreign law or payment system rules may prohibit the processing of a transaction, possibly resulting in the seizure of funds. As a result, this Rule specifically allocates to the Originator of an Outbound IAT Entry (credit or debit) the risk that foreign law or payment system rules may prohibit the processing of that transaction. Under the revised rules, the risk is borne by the ODFI in the relationship between the ODFI and the Gateway, and by the Originator in the relationship between the Originator and the ODFI. Any loss therefore would ultimately accrue to the Originator unless there is an agreement between the Originator and the ODFI, or between the ODFI and the Gateway, to allocate the risk of loss differently (or a different result is required by applicable law or regulation). It is incumbent upon Originators to understand the nature of sending payments to or seeking payments from other countries and the potential risk that international payments processing entails.

IMPACT TO PARTICIPANTSOriginators/ODFIs/Gateways: The narrowing of the ODFI warranty with respect to Outbound IAT Entries should have no operational impact on ACH participants. The reduction in the scope of the warranty and new statement regarding allocation of risk are expected to remove perceived barriers to entry into the international payments arena. It is important to keep in mind, however, the need for Gateways, ODFIs, and Originators to work closely together to ensure that all participants have a sound understanding of international payments processing and any potential risks that such activity entails.

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

• Article Two, Subsection 2.5.8.4 (Additional ODFI Warranties for Outbound IAT Entries) – narrows the scope of subsection 2.5.8.4(b) to limit the requirement to comply with foreign laws and payment system rules to authorization requirements only.

4


• Article Two, Subsection 2.5.8.7 (Assumption of Risk) – adds a new subsection 2.5.8.7 addressing the assumption of risk for Outbound IAT Entries.

Implementation Date: March 15, 2013

• • • •

As approved March 7, 2013, effective March 15, 2013, the Rules are modified as follows for the rule changes specific to ODFI Warranties for Outbound IAT Entries:

ARTICLE TWO

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

SUBSECTION 2.5.8.4 Additional ODFI Warranties for Outbound IAT EntriesIn addition to the other warranties contained within these Rules, an ODFI initiating an Outbound IAT Entry warrants to each RDFI, ACH Operator, and Gateway:

(a) Compliance with U.S. Legal Requirements. The Originator and ODFI are in compliance with U.S. Legal Requirements with respect to the IAT Entry, including their obligations under programs administered by the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC) and the Financial Crimes Enforcement Network (FinCEN).

(b) Compliance with Foreign Payment System Rules. The origination of the IAT Entry complies with the laws and payment system rules of the receiving country.

(b) Compliance with Foreign Laws or Payment System Rules Regarding Authorization. If the laws or payment system rules of the receiving country require authorization with respect to an IAT Entry, the ODFI warrants that the authorization of the IAT Entry complies with the laws and payment system rules of the receiving country.

SUBSECTION 2.5.8.7 Assumption of Risk (new subsection)As between the ODFI and the Gateway of an Outbound IAT Entry, the ODFI bears the risk that the laws of the receiving country prohibit or otherwise preclude the processing, settlement, or transfer of the proceeds of the Entry, including through blocking or other sequestration or seizure of funds, unless otherwise agreed between the Gateway and the ODFI. As between the Originator and the ODFI, the Originator bears all such risk, unless otherwise agreed between the Originator and the ODFI or required by Legal Requirements.

5


Originator Obligations with Respect to Notifications of Change for Single Entries

(Approved March 7, 2013 – Effective September 20, 2013)

SUMMARYThis Rule makes the Originator’s response to Notifications of Change (NOCs) for Single Entry payments optional.

KEY COMPONENTS OF RULE AMENDMENTOriginator Discretion to Act on NOCs Related to Single EntriesThis Rule makes an Originator’s action on changes requested by NOCs related to Single Entries optional, at the Originator’s discretion and based on its particular business model.

Specifically, the Rule defines Originator action on NOCs related to the following SEC Codes as optional: ARC, BOC, POP, RCK, and XCK Entries, as well as TEL and WEB Entries bearing a Single Entry indicator (“S” or “blank” for TEL and “S” for WEB).

RDFI’s Right to Transmit NOCs Related to Single EntriesThe Rule does not change an RDFI’s right to initiate an NOC for any Entry, including those identifiable as Single Entries; however, RDFIs must recognize that changes requested for Single Entries are not required to be made by the Originator.

IMPACT TO PARTICIPANTSOriginators: Originators of Single Entry payments will have discretion in deciding whether to act on changes related to one-time payments, based on their own industry needs and business models. Originators with repeat Single Entry customers (those making weekly grocery purchases or paying monthly utility bills, for example) could benefit from continuing to make changes included in NOCs, while Originators with true one-time purchasers may not find it efficient to maintain the infrastructure needed to house and support corrected data. Each Originator should consider the nature of its business and the likelihood of receiving repeat transactions involving the same customer when determining whether to act on NOCs related to Single Entries.

RDFIs: RDFIs that transmit NOCs in response to Single Entries need to be aware that action on such requests by Originators is optional, at the Originator’s discretion, and that correction to future one-time payments is not guaranteed. RDFIs should take the opportunity to review and ensure the accuracy of checks and other documents available to account holders to obtain routing and account information for ACH Entries. Because checks are the most commonly used source of banking information for ACH Entries, financial institutions are specifically encouraged to verify the validity of check MICR information for ACH processing.

TECHNICAL SUMMARYBelow is a summary of the impact of this rule change on the NACHA Operating Rules. The rule language as it will read upon implementation is shown below.

6


• Article Two, Subsection 2.11.1 – (ODFI and Originator Action on Notification of Change (NOC)) – adds language making the requirement to act on NOCs for specific Single Entry NOCs optional, at the discretion of the Originator.

Implementation Date: September 20, 2013

• • • •

As approved March 7, 2013, effective September 20, 2013, the Rules are modified as follows for the rule changes specific to NOCs for Single Entry payments.

ARTICLE TWO


SUBSECTION 2.11.1 ODFI and Originator Action on Notification of Change (NOC) An ODFI must accept a Notification of Change (also known as “NOC” and “COR Entry”) or a corrected NOC that complies with the requirements of Appendix Five (Notification of Change) and is Transmitted by the RDFI within the time limits established by these Rules, unless otherwise provided for in this Section 2.11.

For each NOC or corrected NOC it receives, an ODFI must provide the Originator with the following minimum information within two Banking Days of the Settlement Date of the NOC or corrected NOC:

(a) company name;

(b) company identification;

(c) company Entry description;

(d) effective Entry date;

(e) DFI account number;

(f) individual name/receiving company name;

(g) individual identification number/identification number;

(h) change code;

(i) original Entry trace number;

(j) original RDFI identification; and

(k) corrected data.

The Originator must make the changes specified in the NOC or corrected NOC within six Banking Days of receipt of the NOC information or prior to initiating another Entry to the Receiver’s account, whichever is later.

7


Except as noted below, the Originator must make the changes specified in the NOC or corrected NOC within six Banking Days of receipt of the NOC information or prior to initiating another Entry to the Receiver’s account, whichever is later. The Originator may choose, at its discretion, to make the changes specified in any NOC or corrected NOC received with respect to any ARC, BOC, POP, RCK, Single-Entry TEL, Single-Entry WEB, and XCK Entry.

8


Stop Payments – Effective Period of Stop Payment for a Non-Consumer Account


SUMMARYThis Rule expands language regarding the effective period of a stop payment order related to a debit Entry to a Non-Consumer Account, incorporating two additional conditions under which a stop order would lapse.

KEY COMPONENTS OF RULE AMENDMENTThis Rule establishes a separate subsection addressing an RDFI’s obligations for maintaining a stop payment order on an Entry to a Non-Consumer Account. In addition to the existing six-month expiration of a stop order, the Rule also recognizes two additional conditions under which an RDFI could remove such a stop payment order: (1) the withdrawal of the stop payment order by the Receiver, or (2) the return of the debit Entry to which the stop payment order relates. The Rule does not impact the existing reference to the six-month effective time period for a stop payment order on an Entry to a Non-Consumer Account, but recognizes that a stop order will lapse at the earliest of one of these three conditions.

IMPACT TO PARTICIPANTSSince this Rule change reflects current industry practice, there are no expected impacts to ACH participants.

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

• Article Three, Subsection 3.7.2 (RDFI Obligation to Stop Payment of Entries to Non-Consumer Accounts) – deletes from this subsection the reference to the effective time period for a stop payment order to a Non-Consumer Account.

• Article Three, Subsection 3.7.2.1 (Effective Period of Stop Payment Orders) – establishes a new subsection specifically addressing the duration of stop payment orders on Entries to Non-Consumer Accounts.


• • • •

As approved March 7, 2013, effective September 20, 2013, the Rules are modified as follows for the rule changes specific to the Effective Period of a Stop Payment Order on a Non-Consumer Account.

9


ARTICLE THREE

Rights and Responsibilities of RDFIs and Their Receivers

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

An RDFI must honor a stop payment order regarding any debit Entry initiated or to be initiated to a non-Consumer Account that is provided by a Receiver at such time and in such manner as to allow the RDFI a reasonable opportunity to act upon the stop payment order prior to acting on the debit Entry. The RDFI must comply with a verbal stop payment order only for a period of fourteen calendar days unless the order is confirmed in writing within that fourteen-day period.

SUBSECTION 3.7.2.1 Effective Period of Stop Payment Orders (New Subsection)A written stop payment order regarding any debit Entry initiated or to be initiated to a non-Consumer Account will remain in effect until the earliest of:

(a) the withdrawal of the stop payment order by the Receiver;

(b) the return of the debit Entry; or,

(c) six months from the date of the stop payment order, unless it is renewed in writing.

10


Identification of Additional Parties to an International Payment Transaction


SUMMARYThis Rule establishes a Gateway obligation and standard formatting requirements for identifying, within an Inbound IAT Entry, the ultimate foreign beneficiary of the proceeds from a debit Inbound IAT Entry or the foreign party ultimately funding a credit Inbound IAT Entry.

BackgroundThe IAT application was originally developed on the basis of a two-party payment model where funds are transferred directly from the payer to the beneficiary. In support of that payment model, the IAT format was designed to convey the name, address, and banking information of both the payer and beneficiary of the funds, with one as the Originator and the other as the Receiver. In most cases, these formatting requirements are sufficient to identify all parties to the payment transaction. However, the industry has determined that international payments can also involve more parties than the two traditionally identified as Originator and Receiver. These are commonly known as “split-transaction” payments or “for-further-credit-to” payments, where a third-party service provider originates and settles two separate transactions to complete the underlying payment transaction on behalf of the parties.

To support the split transaction payment model, the IAT rules need updating to identify key information on all parties to the payment transaction and eliminate the potential risk to ACH participants of doing business with a blocked party. Unlike the more traditional debit Inbound IAT Entry, for example, in which the ultimate payer and ultimate beneficiary are identified as parties to the transaction (i.e., Receiver and Originator, respectively), in the split transaction model, the Originator of the debit Inbound IAT Entry is not the ultimate foreign beneficiary of the funds transfer. Rather, the Originator is a service provider, collecting funds from a U.S. Receiver for further credit to an ultimate foreign beneficiary. Two separate transactions are created and settled to complete the funds transfer – one between the Originator of the debit IAT Entry (the independent service provider) and the party from which funds are being transferred (the Receiver of the debit Inbound IAT Entry), and one between the Originator (the independent service provider) and the ultimate foreign beneficiary of the funds transfer. In this version of the split transaction model, only half of the underlying payment transaction (the domestic debit from the service provider to the U.S. Receiver) is visible within the payment record. The ultimate foreign beneficiary of the funds is not identified, and ACH participants are exposed to the potential risk of indirectly doing business with a blocked party.

Consider the following international split transaction example. Mexican Bank provides a service allowing individuals in the U.S. to send funds easily and economically to relatives and other persons living in Mexico. Mr. Garcia, who lives in El Paso, Texas, uses the service to send money to his mother, Maria Garcia, who lives in Mexico City.

Mr. Garcia logs onto Mexican Bank’s website and instructs it to make a payment to Maria at her bank in Mexico City. Mr. Garcia provides Mexican Bank with Maria’s name, physical address, and banking information for the funds transfer. He also provides Mexican Bank with his own banking information (i.e., the routing number and his account number from which funds will be debited at Southwest Bank) and his address in El Paso.

11


Mexican Bank originates a SWIFT payment instruction to its U.S. correspondent bank, Trust Bank, in New York, requesting it to originate a debit IAT Entry to Mr. Garcia at Southwest Bank and to credit Mexican Bank’s correspondent account at Trust Bank with the amount of the funds. Trust Bank initiates the ACH transaction, as requested, and credits Mexican Bank’s correspondent account. Mexican Bank subsequently does a book entry transfer to move the funds to Mexico for further credit to Maria.

Although both Originator (Mexican Bank) and Receiver (Mr. Garcia) are identified as part of the IAT transaction, the ultimate foreign beneficiary of the funds transfer (Maria Garcia) is not visible to the U.S. RDFI and cannot be screened for OFAC compliance. In this case, the RDFI is not able to determine if its customer is doing business with a blocked party in violation of OFAC sanctions policies and is potentially exposed to significant risk.

The transaction flow of this example is illustrated below.

This Rule reduces the RDFI’s risk of doing business with a blocked party by ensuring that the ultimate foreign beneficiary or foreign payee in an international “for further credit to” arrangement is identified within an Inbound IAT Entry. These changes add clarity to the Rules and facilitate more accurate screening and compliance with OFAC sanctions policies by ACH Participants involved with this payments model.

United States Mexico Mexico

In second transaction, Mexican Bank sends domestic or book transfer credit to Ultimate Beneficiary’sbank/account.

Southwest Bank receives IAT Debit to Mr. Garcia.

IAT Transaction Identifies:1. IAT Originator – MexicanBank 2. IAT Receiver – Mr. Garciaat US RDFI

Credit toaccount ofMaria Garcia

Mexican Bank sendsIAT debit to Southwest Bank and credits own bank account.

Credit

IAT Transaction Does Not Identify:1. Ultimate Beneficiary – Maria Garcia

Mr. Garcia initiates request to send money to Maria Garcia via web service at Mexican

Bank. Provides US RTN/Acct # and all information on Maria

Garcia.

12


KEY COMPONENTS OF RULE AMENDMENTGateway Obligation to Identify Ultimate Foreign Beneficiary/Payer in Inbound IAT EntryThis Rule establishes a Gateway obligation to identify within an Inbound IAT Entry (1) the ultimate foreign beneficiary of the funds transfer when the proceeds from a debit Inbound IAT Entry are for further credit to an ultimate foreign beneficiary that is a party other than the Originator of the debit IAT Entry, or (2) the foreign party ultimately funding a credit Inbound IAT Entry when that party is not the Originator of the credit IAT Entry.

It is important to emphasize that the Gateway (as the party with the direct relationship with the foreign country (either via the foreign Gateway and/or the foreign originator directly)) has the obligation to ensure that all parties to the transaction are appropriately identified within the IAT Entry. Gateways should ensure that their agreements with parties in the foreign country include provisions for the identification of all parties to the payment transaction.

Remittance Addenda Record – Formatting Requirements for Payment Related Information FieldThe Rule revises the description of the Payment Related Information Field as it relates to the IAT Remittance Addenda Record to establish specific formatting requirements for inclusion of the ultimate foreign beneficiary’s/payer’s name, street address, city, state/province, postal code, and ISO Country Code.

Because no more than two remittance addenda records can be included with an IAT Entry, there may be situations in which remittance data and foreign beneficiary/payer data compete for the same space. The identification of the ultimate foreign beneficiary or payer takes priority in any case where a “for further credit to” debit or credit Inbound IAT Entry also contains other payment related information. In other words, a Gateway may need to truncate or supersede other remittance data that would be conveyed within the Payment Related Information field of an IAT remittance addenda record in order to include required information on the ultimate beneficiary/payer of the funds.

IMPACT TO PARTICIPANTSGateways/ODFIs: This Rule reduces Gateways’/ODFIs’ risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that all parties to the payment transaction (including the ultimate beneficiary or payer of the funds) and the countries to/from which such funds are transmitted are clearly identified.

Gateways may incur costs related to educating foreign customers on properly identifying parties and places connected to the funds transfer.

ACH software may require modification in order to include the ultimate foreign beneficiary’s/payer’s information in the proper format within the Payment Related Information Field of an Inbound IAT Entry. Costs associated with such changes are expected to be minimal. By contrast, the cost of not including the information on the ultimate beneficiary/payer and having a financial institution receive an OFAC sanction and penalty for indirectly doing business with a blocked party can be monetarily significant, in addition to having a negative impact to the reputation of the financial institution and the ACH Network.

The Rules do not require mandatory compliance with this change until March 21, 2014; however, Gateways are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies.

RDFIs: This Rule reduces RDFIs’ risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that all parties to the payment transaction (including the ultimate beneficiary or payer of the funds) and the countries to/from which such funds are transmitted are clearly identified.

13


ACH software may require modification in order to include the ultimate foreign beneficiary’s/payer’s information in the proper format within the Payment Related Information Field of an Inbound IAT Entry. Costs associated with such changes are expected to be minimal. By contrast, the cost of not including the information on the ultimate beneficiary/payer and having a financial institution receive an OFAC sanction and penalty for indirectly doing business with a blocked party can be monetarily significant, in addition to having a negative impact to the reputation of the financial institution and the ACH Network.

The Rules do not require mandatory compliance with this change until March 21, 2014; however, RDFIs are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies.


• Article Five, Subsection 5.1.3 (Gateway Obligation to Identify Ultimate Foreign Beneficiary or Payer of Funds in Inbound IAT Entry) – adds a new subsection requiring Gateways to populate the Payment Related Information field with the name and address of the ultimate foreign beneficiary of funds from in Inbound IAT debit or the ultimate foreign payer of funds for an Inbound IAT credit when that party is not the Originator of the IAT Entry.

• Appendix Three (ACH Record Format Specifications), Subpart 3.2.2 (Glossary of Data Elements) – Payment Related Information – revises the Payment Related Information field description to require the ultimate foreign beneficiary/payer to be identified within this field when the payment is part of a split transaction payment model.


• • • •

As approved March 7, 2013, effective March 21, 2014, the Rules are modified as follows for the rule changes specific to the Identification of Additional Parties to an International Payment Transaction.

ARTICLE F IVE

Rights and Responsibilities of Gateways for IAT Entries

Subsection 5.1.3 – Gateway Obligation to Identify Ultimate Foreign Beneficiary or Payer of Funds in Inbound IAT Entry (New Subsection)A Gateway must identify within an Inbound IAT Entry (1) the ultimate foreign beneficiary of the funds transfer when the proceeds from a debit Inbound IAT Entry are for further credit to an ultimate foreign beneficiary that is a party other than the Originator of the debit IAT Entry, or (2) the foreign party ultimately funding a credit Inbound IAT Entry when that party is not the Originator of the credit IAT Entry. The Gateway must include the ultimate foreign beneficiary’s or payer’s name, street address, city, state/province, postal code, and two-character alphabetic ISO country code (as defined within the International Organization for Standardization’s 3166-1-alpha-2 code list) within the Payment Related Information Field of the IAT Remittance Addenda Record, as required by Appendix Three (ACH Record Format Specifications) of these Rules.

14


APPENDIX THREE

ACH Record Format Specifications

Subpart 3.2.2 – Glossary of Data ElementsPayment Related Information: 80 Positions – Addenda Record – Optional (ACK, ATX, CCD, CIE, CTX, DNE, ENR, IAT, PPD, TRX, WEB)

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

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

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

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

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

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

For Example:

N1*BT*JohnDoe\N3*12MainStreet\N4*21070\

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

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

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

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

15


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

DATE OF DEATH*MMDDYY*CUSTOMERSSN*

#########*AMOUNT*$$$$.cc\

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

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

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

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

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

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

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

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

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

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

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

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

For Example:

22*12200004*3*123987654321*777777777*DOE*JOHN*0\

22*12200004*3*987654321123*876543210*ABCCOMPANY**B\

27*12200004*3*987654321123*876543210*ABCELECTRONICIN*DUSTRIE*B\

16


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

Identification of Ultimate Foreign Beneficiary/Payer - For Inbound IAT Entries, this field must contain the ultimate foreign beneficiary’s or payer’s name, street address, city, state/province, postal code, and two-character alphabetic ISO country code (as defined within the International Organization for Standardization’s 3166-1-alpha-2 code list) when:

(1) the proceeds from a debit Inbound IAT Entry are for further credit to an ultimate foreign beneficiary that is a party other than the Originator of the debit IAT Entry; or

(2) the funding for a credit Inbound IAT Entry is ultimately from a foreign party that is not the Originator of the credit IAT Entry.

The identification of the ultimate foreign beneficiary (of the debit) or ultimate foreign payer (of the credit) takes priority over the inclusion of other payment related information.

For example:

Johann Schmidt*Mainzer Landstrasse 201*60326 Frankfurt am Main*DE\

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

CHECK SERIAL NUMBER\

For example: 3349809002\

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

CHECK SERIAL NUMBER (MAXIMUM OF 9 CHARACTERS)*TERMINAL CITY (MAXIMUM OF 4 CHARACTERS)*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\

For example: 123456789*PARI*FR\

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

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

For example:

200509*321 EAST MARKET STREET*ANYTOWN*VA\

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

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

17


Identification of Country Names Within IAT Entries


SUMMARYThis Rule clarifies the manner in which countries must be identified within an IAT Entry, eliminating the potential for ambiguity in identifying countries to or from which IAT entries are directed.

KEY COMPONENTS OF RULE AMENDMENTThis Rule requires an Originator, Third-Party Sender, ODFI, or Gateway transmitting an IAT Entry to identify any country named within the IAT Entry by that country’s 2-digit alphabetic ISO Country Code, as defined by the International Organization for Standardization’s (ISO) 3166-1-alpha-2 code list. This clarification affects the following fields:

• ISO Destination Country Code (IAT Company/Batch Header Record)

• Originator Country & Postal Code (Third IAT Addenda Record)

• Originating DFI Branch Country Code (Fourth IAT Addenda Record)

• Receiving DFI Branch Country Code (Fifth IAT Addenda Record)

• Receiver Country & Postal Code (Seventh IAT Addenda Record)

• Payment Related Information Field (IAT Addenda Record for Remittance Information)

• Foreign Correspondent Bank Branch Country Code (IAT Addenda Record for Foreign Correspondent Bank Information)

The potential for errors, both in populating the fields and in screening for OFAC compliance, is substantially reduced by the use of standardized codes within the Originator Country and Postal Code field and the Receiver Country and Postal Code field (the third and the seventh addenda records, respectively), which currently are ambiguous with respect to the formatting of the country name. Clarifying the specific ISO country code list to be used in fields already requiring a 2-digit country code ensures a consistent manner of identification for any country listed within an IAT Entry.

IMPACT TO PARTICIPANTSAll ACH Participants: This Rule reduces ACH participants’ risk of doing business with blocked parties in violation of OFAC sanctions policies by ensuring that the countries to/from which such funds from payment transactions are transmitted are clearly identified. The Rule improves the efficiency of the OFAC screening process by establishing a single standard for identifying countries involved in the payment transaction. In particular, clear identification of the countries in the third and seventh addenda records through the use of ISO Country Codes improves the efficiency of interdiction software and reduces false positives related to country identification.

This Rule is not expected to have any direct impact on ACH formats or systems; however, some ACH participants may choose to make coding changes to their software to enable drop-down menus from which Originators, ODFIs, and Gateways may choose the appropriate ISO country code, and ACH participants may incur costs related to software modifications needed to adopt the standardized list of

18


country codes. Gateways may incur costs related to educating foreign customers on properly identifying parties and places connected to the funds transfer. Software modifications may be needed to OFAC interdiction software to ensure that only ISO codes are used to identify countries within ACH transactions.

Mandatory compliance with this change is not required until March 21, 2014; however, ACH participants are encouraged to adopt this change as soon as practical to minimize the potential for violations of OFAC sanctions policies.


• Appendix Three (ACH Record Format Specifications), Subpart 3.2.2 (Glossary of Data Elements) – revises the field descriptions listed below to require use of ISO’s 2-digit alphabetic country code values from its 3166-1-alpha-2 country code list when identifying any country within an IAT Entry:

– ISO Destination Country Code – Originator Country & Postal Code – Originating DFI Branch Country Code – Receiving DFI Branch Country Code – Receiver Country & Postal Code – Payment Related Information Field – Foreign Correspondent Bank Branch Country Code


• • • •

As approved March 7, 2013, effective March 21, 2014, the Rules are modified as follows for the rule changes specific to the Identification of Country Names within IAT Entries.

APPENDIX THREE


SUBPART 3.2.2 Glossary of Data Elements Foreign Correspondent Bank Branch Country Code: 3 positions – Addenda Record – Mandatory (IAT)

This field contains a 2-character code as approved by the International Organization for Standardization (ISO) used to identify the country in which the branch of the Foreign Correspondent Bank is located.

This field contains a two-character alphabetic country code, as defined within the International Organization for Standardization’s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the Foreign Correspondent Bank is located.

ISO Destination Currency Code: 3 Positions – Company/Batch Header Record – Mandatory (IAT, Returns, COR)

19


This field contains the three-character code, as approved by the International Organization for Standardization (ISO), to identify the currency denomination in which the Entry is to be received.

This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization’s (ISO) 3166-1-alpha-2 code list, to identify the country in which the Entry is to be received.

Originating DFI Branch Country Code: 3 Positions – Addenda Record – Mandatory (IAT)

This field contains a 2-character code, as approved by the International Organization for Standardization (ISO), to identify the country in which the branch of the bank that originated the Entry is located. This code must correspond to the country in which the bank branch identified within the Originating DFI Identification field of the Fourth IAT Addenda Record is located.

This field contains a two-character alphabetic country code, as defined within the International Organization for Standardization’s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the bank that originated the Entry is located. This code must correspond to the country in which the bank branch identified within the Originating DFI Identification field of the Fourth IAT Addenda Record is located.

Originator Country and Postal Code: 35 Positions – Addenda Record – Mandatory (IAT)

This field contains the country and postal code of the Originator. An asterisk (“*”) must be used as the delimiter between the data elements, and the backslash (“\”) must be used as the terminator following the last data element.

This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization’s 3166-1-alpha-2 code list, and the postal code of the Originator. An asterisk (“*”) must be used as the delimiter between the data elements, and the backslash (“\”) or the tilde (“~”) must be used as the terminator following the last data element.

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




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

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

20



For Example:



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

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

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



#########*AMOUNT*$$$$.cc\





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


21








For Example:

22*12200004*3*123987654321*777777777*DOE*JOHN*0\

22*12200004*3*987654321123*876543210*ABCCOMPANY**B\



IAT: This field contains 80 characters of payment related information. When the payment related information for an IAT Entry includes the identification of a country, that country must be identified using that country’s two-character alphabetic country code, as defined within the International Organization for Standardization’s 3166-1-alpha-2 code list. (Note: A maximum of two optional Addenda Records may be used for IAT remittance information.)







22



TERMINAL IDENTIFICATION CODE(MAXIMUM OF 6 CHARACTERS)*TERMINAL LOCATION (MAXIMUM OF 27 CHARACTERS)*TERMINAL CITY)MAXIMUM OF 15 CHARACTERS)

*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\

For example:




Receiver Country and Postal Code: 35 Positions – Addenda Record – Mandatory (IAT)

This field contains the country and postal code of the Receiver. An asterisk (“*”) must be used as the delimiter between the data elements, and the backslash (“\”) must be used as the terminator following the last data element.

This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization’s 3166-1-alpha-2 code list, and the postal code of the Receiver. An asterisk (“*”) must be used as the delimiter between the data elements, and the backslash (“\”) or the tilde (“~”) must be used as the terminator following the last data element.

Receiving DFI Branch Country Code: 3 Positions – Addenda Record – Mandatory (IAT)

This field contains a 2-character code, as approved by the International Organization for Standardization (ISO), to identify the country in which the branch of the bank that receives the Entry is located.

This field contains the two-character alphabetic country code, as defined within the International Organization for Standardization’s (ISO) 3166-1-alpha-2 code list, to identify the country in which the branch of the bank that received the Entry is located.

23


Person-to-Person Payments via ACH

(Approved March 7, 2013 – Effective March 21, 2014; mandatory use by ODFIs and Third-Party Senders by March 20, 2015)

SUMMARY This Rule standardizes the use of the ACH Network for Person-to-Person (P2P) Entries. Specifically, this Rule:

• Defines a P2P Entry within the Rules; clarifies the definition of CIE Entry for use with bill payments made to Non-Consumer Receivers;

• Enables a credit version of the WEB Standard Entry Class (SEC) Code to be used for a P2P credit transaction transmitted from one consumer account to another;

• Addresses rules exceptions and additional indemnifications unique to credit WEB Entries;

• Establishes specific periodic statement requirements for credit WEB Entries;

• Establishes standardized formatting requirements for credit WEB Entries, including the use of Addenda Records; and

• Clarifies within the Rules how Notifications of Change (NOCs) should be handled for P2P WEB credits and for bill payment CIEs.

Background Currently, the Rules do not specifically address person-to-person (P2P) payments. Many financial institutions and non-financial institutions, however, are either offering these payments over the ACH Network already, or plan to in the near future. In the absence of more specific Rules language or guidance, financial institutions and other entities offering P2P payments rely on their own understanding and interpretation of the Rules in designing and implementing P2P payment services that use the ACH Network. One effect of this is that RDFIs might receive P2P transactions for their consumer account holders that are formatted in a variety of different ways.

This Rule provides clarity and consistency to ODFIs, RDFIs, Originators, and Third Parties about how to apply the Rules to P2P payments, and ensures standard formatting for RDFIs’ use in providing transaction information to their customers.

KEY COMPONENTS OF RULE AMENDMENTDefinitions of Terms – Person-to-Person Entry (P2P) and Customer-Initiated Entry (CIE)This Rule defines a Person-to-Person (P2P) Entry as “a credit Entry initiated by or on behalf of a holder of a Consumer Account that is intended for a Consumer Account of a Receiver.”

The Rule also modifies the definition of a Customer Initiated Entry (CIE) to “a credit Entry initiated by or on behalf of the holder of a Consumer Account to the Non-Consumer Account of a Receiver.”

These definitional changes ensure there is a clear differentiation between WEB credit and CIE – CIE for a bill payment from a consumer to a business, and WEB credit for a P2P payment from one consumer to another or between accounts belonging to the same person.

24


Expansion of WEB SEC Code for P2P EntriesThis Rule expands the WEB SEC Code to accommodate credit Entries transmitted between consumers (P2P transactions). A WEB credit Entry may be either a single entry or a recurring payment, denoted (like WEB debits) by a value of “S” or “R” in the Payment Type Code field of the Entry Detail Record.

The use of a credit WEB Entry provides clear identification of a P2P transaction for special handing and tracking needs. WEB credits may also be batched together with WEB debit entries, which are commonly used in split transaction payment models to fund P2P transactions.

All P2P Entries must be originated as WEB credit Entries, regardless of the manner in which the payment is initiated. While most P2P payments are originated electronically via the Internet or using a mobile device, P2P payments may also be originated by other means, such as an in-person instruction provided at a bank branch. A WEB credit is appropriate in either case.

Rules Exceptions for Credit WEB EntriesODFI/Originator AgreementUnlike most origination activity, an Originator of a P2P Entry is not required to enter into an origination agreement with the ODFI in order to transmit credit WEB Entries. The requirements of an ODFI/Originator agreement are not suitable to transactions in which a consumer is the Originator and thus are not applicable. This is consistent with the requirements for CIE Entries, which are also exempted from the requirements for an ODFI/ Originator agreement because the originator is a consumer.

Receiver AuthorizationSince a P2P Entry is intended to involve a credit between natural persons, no authorization by the Receiver is required for credit WEB entries.

ODFI Risk ManagementODFIs are not required to perform risk management functions defined under Article Two, subsection 2.2.2 (ODFI Risk Management) with respect to consumer Originators of credit WEB Entries since these ODFI obligations (i.e., an assessment of the nature of the originator’s ACH activity; establishment, implementation, and review of an exposure limit; monitoring of return activity across multiple settlement dates; enforcement of restrictions on origination; and enforcement of exposure limits) are not suitable to Originators that are individual consumers.

However, the ODFI must fulfill all appropriate risk management requirements for Third-Party Senders that act on behalf of consumer Originators.

Additional ODFI Warranties for WEB EntriesODFI warranties related to the Originator’s use of commercially reasonable fraud detection systems, methods of verifying the Receiver’s identity, and methods of verifying the validity of routing numbers do not apply to credit WEB Entries. Because credit WEB Entries involve a consumer Originator, the use of these risk control measures are not suitable. Rules language regarding an Originator’s compliance with these requirements is revised to apply only to debit WEB Entries.

Additional ODFI Indemnification for Credit WEB EntriesIn addition to the general indemnifications the ODFI makes to the RDFI with respect to any ACH Entry, the ODFI of a credit WEB Entry also indemnifies and holds harmless any RDFI that suffers any loss or liability from accurately providing the contents of the Payment Related Information field to the Receiver.

25


Formatting Requirements for WEB CreditsUse of Individual Identification Number Field to Identify Originator (Sender) of P2P EntryThis Rule requires P2P service providers (i.e., ODFIs or Third-Party Service Providers) to identify the Originator (the sender) of the P2P payment within the Individual Identification Number field of the WEB credit’s Entry Detail Record.

Use of Company Name Field to Identify P2P Service ProviderThis Rule requires P2P service providers (i.e., the consumer’s ODFI or the Third-Party Service Provider) to identify itself within the Company Name field of the Company/Batch Header Record.

Company Entry DescriptionThe Rule requires the Company Entry Description field within the Company/Batch Header Record to contain a descriptive statement that identifies the P2P transaction in a way that is meaningful to the consumer. For example, the text could use “P2P,” or it could refer to the trade name of a specific P2P payment service.

Payment Related InformationThis Rule allows ODFIs to make available up to 80 characters of plain-text remittance information with a credit WEB Entry. While ODFIs and/or Third Party Senders must ensure that valid characters are used within the Payment Related Information field of the credit WEB Entry’s addenda record (see ACH File Exchange Specifications within Appendix One of the Rules), ODFIs and Third Party Service Providers will not need to ensure that remittance data is conveyed within ANSI ASC X12 data segments or NACHA-endorsed banking conventions.

Periodic StatementsODFIsBecause a credit WEB Entry is originated by a consumer customer of the ODFI (similar to CIE), the ODFI is required to satisfy periodic statement requirements in accordance with Regulation E and NACHA Operating Rules by providing certain transaction information to the consumer Originator of a WEB credit. This information includes the posting date to the consumer Originator’s account; the dollar amount of the Entry; the payee name, etc.

RDFIsRDFIs must properly identify the sender of a credit WEB Entry on the Receiver’s periodic statement and other transaction reports (e.g., online statement) in order to comply with Regulation E. For credit WEB Entries, the sender of the funds is identified within the Individual Identification Number field of the Entry Detail Record rather than the Company Name field of the Company/Batch Header Record. RDFIs need to to provide the contents of the Individual ID Number field on the Receiver’s periodic statement and other transaction reports.

Some Originators make a practice of including a consumer’s SSN or ITIN or other personally identifiable information in the Individual ID Number field for other SEC Codes. While the contents of this field must be provided for credit WEB Entries, NACHA generally recommends for other types of Entries that RDFIs avoid, to the extent possible, displaying the contents of this field on documents that may be mailed or otherwise delivered to a consumer in an unsecure manner.

Note: While this Rule does not require the RDFI to provide the consumer Receiver with any Payment Related Information that may be transmitted with a Credit WEB Entry, it may do so at its discretion. If it does so, the ODFI indemnifies the RDFI against any loss or liability associated with the accurate provision of that remittance information.

26


Because the placement of the sender’s name in a credit WEB entry differs from other ACH Entries, RDFIs will need to make coding changes to accommodate this information on consumers’ periodic statements. It is important that RDFIs address these issues prior to the March 2014 effective date of this rule to stay compliant with the requirements of Regulation E.

As with all rule changes, the 2014 NACHA Operating Guidelines will be updated to incorporate guidance related to P2P payments and the use of credit WEB Entries. In the interim, anticipated changes related to RDFIs’ statement obligations for consumer entries (Guidelines Chapter 23 – Relationship with Receiver) are provided below to draw specific attention to the location of the sender of the credit WEB Entry.

CONSUMER RECEIVERSThe NACHA Operating Rules require RDFIs of entries to consumer accounts to provide certain information about those entries to the Receiver, known as statement requirements. The RDFI must provide or make available the following information for each debit and credit entry:

1. Posting date to Receiver’s account;2. Dollar amount of the entry;3. Company/Originator name; (Note: For credit WEB Entries for P2P payments, which

become effective March 21, 2014, the name of the consumer Originator will be located within the Individual Identification Number field of the Entry Detail Record)

4. Company Entry description;5. Account type;6. Account number;7. Amount of any charges assessed against the account for services related to the

entry;8. Balances in the Receiver’s account at the beginning and at the close of the statement

period;9. For an ARC, BOC, RCK or XCK Entry, or an IAT Entry where the Transaction Type

Code field contains a value of “ARC,” “BOC,” or “RCK,” the Check Serial Number;10. For an MTE, POS or SHR Entry, or an IAT Entry where the Transaction Type Code

field contains a value of “MTE,” “POS,” or “SHR,” the: • Terminal identification code and/or terminal location, as those terms are

defined in Regulation E; • Terminal city, as that term is defined in Regulation E; and • Terminal state, as that term is defined in Regulation E;

11. For a POP Entry, or an IAT Entry where the Transaction Type Code field contains a value of “POP,” the:

• Check Serial Number; • Terminal city, as that term is defined in Regulation E; and • Terminal state, as that term is defined in Regulation E;

12. Address and telephone number to be used for inquiries or notices of errors preceded by “Direct Inquiries To” or similar language.

These requirements do not apply to passbook accounts that do not accept electronic funds transfers other than preauthorized credit transfers.

The RDFI is not required to keep a file of authorizations for consumer transactions. The RDFI may rely on the warranties of the ODFI, which is responsible for ensuring the authorization

27


is in place. However, the RDFI may request, in writing, that the ODFI provide a copy of the consumer’s authorization for all Standard Entry Class Codes, except MTE, SHR and XCK entries.

An RDFI must identify the name of the party to/from whom funds are transferred on the Receiver’s periodic statement and other transaction reports (e.g., online statement) in order to comply with Regulation E. For most ACH transactions, this information is located within the Company Name field or the Originator Name field of the Company/Batch Header Record. RDFIs must be aware that, effective March 21, 2014, credit WEB Entries will identify the sender (consumer Originator) of the funds within the Individual Identification Number field of the Entry Detail Record rather than in either of the two fields noted above. While the contents of the Individual Identification Number field must be conveyed to the Receiver for credit WEB Entries, NACHA generally recommends that RDFIs avoid (to the extent possible) displaying the contents of this field for other types of Entries on any documents that are mailed or otherwise delivered to the consumer in an unsecure manner, since some Originators include a consumer’s Social Security Number, ITIN, or other personally identifiable information within the Individual Identification Number field.

Notifications of Change (NOCs) for P2P WEB Credits and Bill Payment CIEsThis Rule clarifies the treatment of NOCs related to credit WEB Entries and CIE Entries. (While the Rule focuses primarily on P2P payments rather than bill payments, CIE Entries are included here because the required action upon receipt of an NOC is the same for both SEC Codes as consumer-initiated credits.) The Rule applies to scenarios in which a financial institution provides its own bill payment or P2P services, and to scenarios in which a Third Party Service Provider is utilized for P2P and bill payment services.

Specifically, when a CIE or WEB credit NOC is received by the ODFI, the ODFI must make the changes itself, or provide the bill payment or P2P provider with the necessary information, within two Banking Days of the Settlement Date of the NOC or corrected NOC. In the case of credit WEB Entries and CIE Entries, a consumer customer is the Originator of the Entry and is not likely to be in a position to receive or make these changes. As a result, it is the financial institution and/or third-party bill payment/P2P service provider that should be using the information in the NOC to update its systems. Just like any other NOC, the bill payment/P2P provider must make the changes specified in the NOC or corrected NOC within six Banking days of receipt of the NOC information or prior to initiating another Entry to the Receiver’s account, whichever is later.

OTHER ISSUES TO CONSIDEROriginator Action on NOCs for Single EntriesOn September 20, 2013, an unrelated change to NOC rules becomes effective, making an Originator’s response to NOCs optional for Single Entry payments, at the Originator’s discretion. Because credit WEB Entries may be either recurring or Single Entry transactions (denoted by a value of “R” or “S” in the Payment Type Code field), ODFIs and/or Third Party Service Providers receiving an NOC in response to a credit WEB Entry must identify which type of Entry (recurring or Single Entry) the credit WEB Entry is in order to determine their obligations to respond to an NOC. ODFIs/Third Parties will be required to act on any NOC transmitted with respect to a recurring credit WEB Entry but will have discretion in responding to NOCs transmitted with respect to a Single Entry credit WEB Entry.

ODFIs/Third Parties must continue to make any NOC changes related to CIE Entries, which do not distinguish between recurring and Single Entry payments and are not impacted by this additional NOC change.

28


ReversalsThis Rule does not address the use of Reversals for credit WEB Entries. However, NACHA recommends that ODFIs consider prohibiting a consumer Originator of a credit WEB Entry from originating a Reversal for such an Entry without the intervention of the ODFI or its Third Party Service Provider, since doing so would result in one consumer’s debiting another consumer’s account. Instead, NACHA recommends that third party service providers or ODFIs originate any necessary reversing entries if such corrections are warranted and in accordance with the Rules.

IMPACT TO PARTICIPANTSOriginators: Consumer Originators should not incur any direct impact or costs as a result of the adoption of these changes.

ODFIs/Third Party Service Providers/Third Party Senders: Each ODFI, Third Party Service Provider, or Third Party Sender offering P2P services will incur programming costs to adopt the use of the new credit WEB Entry format (including the use of plain text remittance data) and to prepare to satisfy periodic statement requirements by providing certain transaction information to the consumer Originator of a WEB credit. ODFIs, Third Party Service Providers, and Third-Party Senders need to be aware of the additional indemnification they make to RDFIs with respect to the Originator’s inclusion of plain text remittance data within the Payment Related Information field and should consider whether updates to their agreements with P2P customers are needed to address this issue. ODFIs and Third Parties will need to examine their audit procedures to make necessary modifications with respect to the handling of NOCs for credit WEB Entries and CIE Entries. ODFIs and Third Parties should examine their policies and procedures related to NOCs and Reversals to determine whether any changes are needed. ODFIs and Third Parties may also bear some customer service and training costs associated with the Rule.

ODFIs, Third Party Service Providers, and Third-Party Senders need to ensure that their systems utilize the appropriate SEC codes for payments initiated by their consumer Originators – credit WEB Entries for P2P payments, and CIE Entries for bill payment transactions. ODFIs, Third Party Service Providers, and Third-Party Senders may use the credit WEB SEC Code for P2P entries beginning March 21, 2014, but must ensure that all P2P entries are originated as credit WEB Entries by March 20, 2015.

For credit WEB Entries, ODFIs and Third-Parties should follow existing Rules and regulatory guidance on data security and customer authentication, including the June 2011 FFIEC supplement to the Authentication in an Internet Banking Environment guidance. As with the initiation of any type of ACH Entry, the initiation of a credit WEB Entry (online or mobile) must be consistent with the Rules around the secure transmission of ACH information.

RDFIs: RDFIs will incur programming costs to adopt the use of the new credit WEB Entry. RDFIs must identify the sender of the funds on the Receiver’s periodic statement and other transaction reports (e.g., online statement) to comply with Regulation E. RDFIs that do not already provide information found in the Individual ID Number field of the Entry Detail Record on the periodic statement will incur costs to change their systems to extract that information for use on the periodic statement to meet Regulation E statement requirements. Some Originators make a practice of including a consumer’s SSN or ITIN or other personally identifiable information in the Individual ID Number field for other SEC Codes. While the contents of this field must be provided for credit WEB Entries, NACHA generally recommends for other types of Entries that RDFIs avoid, to the extent possible, displaying the contents of this field on documents that may be mailed or otherwise delivered to a consumer in an unsecure manner. While this Rule does not require the RDFI to provide the consumer Receiver with any Payment Related Information that may be transmitted with a Credit WEB Entry, an RDFI may do so at its discretion. In such cases, programming changes will likely be necessary. RDFIs may also bear some customer service and training costs associated with the Rule.

29


Receivers: Consumer Receivers should not incur any direct costs as the result of the adoption of these changes.


• Article Two, Subsection 2.5.4.1 (General Rule for CIE Entries) – modifies the definition of CIE to include the words “Non-Consumer”.

• Article Two, Subsection 2.5.17.1 (General Rule for WEB Entries) – modifies the definition of WEB to add WEB credits for P2P payments.

• Article Two, Subsection 2.5.17.2 (Authorization of Debit WEB Entries) – modifies the language to clarify that it applies only to debit WEB Entries.

• Article Two, Subsection 2.5.17.4 (Additional ODFI Warranties for Debit WEB Entries) – modifies the language to clarify that it applies only to debit WEB Entries.

• Article Two, Subsection 2.5.17.5 (Additional Indemnity for Credit WEB Entries) – adds subsection providing indemnification to RDFIs for accurately communicating information from the Payment Related Information field.

• Article Two, Subsection 2.5.17.6 (ODFI to Satisfy Periodic Statement Requirement for Credit WEB Entries) – adds subsection requiring ODFIs to provide information with respect to the Consumer Account of the Originator of a credit WEB Entry.

• Article Two, Subsection 2.5.17.7 (Rules That Do Not Apply to Credit WEB Entries) – adds subsection to clarify that Subsections 2.2.1.1 (ODFI Must Enter Origination Agreement with Originator) and 2.2.2 (ODFI Risk Management) do not apply to credit WEB Entries.

• Article Two, Subsection 2.11.1 (ODFI and Originator Action on Notification of Change (NOC) – modifies subsection to include service providers if applicable, for CIE and credit WEB Entries.

• Article Eight, Subsection 8.22 – modifies the definition of Customer Initiated Entry or CIE Entry or CIE to include the words “Non-Consumer”.

• Article Eight, Subsection 8.48 – modifies the definition of Internet-Initiated / Mobile Entry or WEB Entry or WEB to include credit WEB Entries for use for Person-to-Person (P2P) payments.

• Article Eight, Subsection 8.64 – defines Person-to-Person (P2P) Entry within the Rules.

• Appendix Two, Subpart 2.5 (Automatic Entry Detail Rejection Criteria) – modifies the description of R36 (Return of Improper Credit Entry) to remove WEB as an SEC Code not permitted for use with credit Entries.

• Appendix Three, Subpart 3.2.2 (Glossary of Data Elements) – expands the descriptions of the following fields to accommodate formatting requirements specific to credit WEB Entries and Addenda Record changes:

30


– Company Entry Description – Company Name – Individual Identification Number – Payment Related Information

• Appendix Eight, Part 8.4 (Audit Requirements for ODFIs) – expands requirement on NOCs to include provision of information to service providers

Implementation Date: March 21, 2014 (Note: ODFIs, Third-Party Senders and Third-Party Service Providers must convert all P2P origination volume to the credit WEB Entry format no later than March 20, 2015.)

• • • •

As approved March 7, 2013, effective March 21, 2014, the Rules are modified as follows for the rule changes specific to P2P Payments via ACH.

ARTICLE TWO


SUBSECTION 2.5.4.1 General Rule for CIE Entries A CIE Entry is a credit Entry initiated by or on behalf of the holder of a Consumer Account to the account of a Receiver.

A CIE Entry is a credit Entry initiated by or on behalf of the holder of a Consumer Account to the Non-Consumer Account of a Receiver.

SUBSECTION 2.5.17.1 General Rule for WEB Entries A WEB Entry is a debit Entry to a Consumer Account originated 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. An ODFI must perform, or ensure that its Originator or Third-Party Sender performs, the requirements of Subsection 2.5.17.2 (Authorization of WEB Entries) and Subsection 2.5.17.3 (WEB Annual Audit) below before permitting an Originator or Third-Party Sender to initiate a WEB Entry.

A debit WEB Entry is a debit Entry to a Consumer Account originated 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. An ODFI must perform, or ensure that its Originator or Third-Party Sender performs, the requirements of Subsection 2.5.17.2 and Subsection 2.5.17.3 below before permitting an Originator or Third-Party Sender to initiate a WEB Entry.

31


A credit WEB Entry is a credit Entry initiated by or on behalf of the holder of a Consumer Account that is intended for a Consumer Account of a Receiver, regardless of whether the authorization is communicated via the Internet or Wireless Network.

SUBSECTION 2.5.17.2 Authorization of WEB Entries An Originator must satisfy the requirement for authorization of a WEB Entry to a Consumer Account of the Receiver by (1) obtaining written authorization from the Receiver via the Internet or a Wireless Network; or (2) obtaining the Receiver’s authorization in any manner permissible under Subsection 2.3.2 (Authorizations and Notices with Respect to Consumer Accounts), and the Receiver’s instruction for the initiation of the individual debit Entry is communicated, other than by an oral communication, via a Wireless Network.

SUBSECTION 2.5.17.2 Authorization of Debit WEB EntriesAn Originator must satisfy the requirement for authorization of a debit WEB Entry to a Consumer Account of the Receiver by (1) obtaining written authorization from the Receiver via the Internet or a Wireless Network; or (2) obtaining the Receiver’s authorization in any manner permissible under Subsection 2.3.2 (Authorizations and Notices with Respect to Consumer Accounts), and the Receiver’s instruction for the initiation of the individual debit Entry is communicated, other than by an oral communication, via a Wireless Network.

SUBSECTION 2.5.17.4 Additional ODFI Warranties for WEB Entries In addition to the other warranties contained within these Rules, an ODFI originating a WEB Entry warrants to each RDFI and ACH Operator that:

(a) Fraud Detection Systems. The Originator has established and implemented a commercially reasonable fraudulent transaction detection system to screen the WEB Entry.

(b) Verification of Receiver’s Identity. The Originator has established and implemented commercially reasonable methods of authentication to verify the identity of the Receiver of the WEB Entry.

(c) Verification of Routing Numbers. The Originator has established and implemented commercially reasonable procedures to verify that the routing number used in the WEB Entry is valid.

SUBSECTION 2.5.17.4 Additional ODFI Warranties for Debit WEB EntriesIn addition to the other warranties contained within these Rules, an ODFI originating a debit WEB Entry warrants to each RDFI and ACH Operator that:

(a) Fraud Detection Systems. The Originator has established and implemented a commercially reasonable fraudulent transaction detection system to screen the WEB Entry.

(b) Verification of Receiver’s Identity. The Originator has established and implemented commercially reasonable methods of authentication to verify the identity of the Receiver of the WEB Entry.

(c) Verification of Routing Numbers. The Originator has established and implemented commercially reasonable procedures to verify that the routing number used in the WEB Entry is valid.

SUBSECTION 2.5.17.5 Additional Indemnity for Credit WEB Entries (new subsection)An ODFI shall indemnify each RDFI from and against any and all claims, demands, losses, liabilities, and expenses, including attorneys’ fees and costs, that result directly or indirectly from the RDFI’s accurate communication or display to a Receiver of any information provided within the Payment Related Information field of an Addenda Record Transmitted by the ODFI with a credit WEB Entry.

32


SUBSECTION 2.5.17.6 ODFI to Satisfy Periodic Statement Requirement for Credit WEB Entries (new subsection)An ODFI must provide or make available the following information with respect to the Consumer Account of the Originator of a credit WEB Entry:

(a) posting date to the Originator’s account;

(b) dollar amount of the Entry;

(c) payee name;

(d) Entry description;

(e) account type;

(f) account number;

(g) amount of any charges assessed against the account for services related to the Entry;

(h) balances in the Originator’s account at the beginning and at the close of the statement period; and

(i) address and telephone number to be used for inquiries or notices of errors preceded by “Direct Inquiries To” or similar language.

References to data elements contained in an Entry are further defined in Appendix Three (ACH Record Format Specifications). The requirements of this subsection apply regardless of whether Regulation E imposes similar requirements on the ODFI.

SUBSECTION 2.5.17.7 Rules That Do Not Apply to Credit WEB Entries (new subsection)The following subsections do not apply to credit WEB Entries:

(a) Subsection 2.2.1.1 (ODFI Must Enter Origination Agreement with Originator); and

(b) Subsection 2.2.2 (ODFI Risk Management), to the extent applicable to Originators.

SUBSECTION 2.11.1 ODFI and Originator Action on Notification of Change (NOC) An ODFI must accept a Notification of Change (also known as “NOC” and “COR Entry”) or a corrected NOC that complies with the requirements of Appendix Five (Notification of Change) and is Transmitted by the RDFI within the time limits established by these Rules, unless otherwise provided for in thisSection 2.11.

For each NOC or corrected NOC it receives, an ODFI must provide the Originator with the following minimum information within two Banking Days of the Settlement Date of the NOC or corrected NOC:

(a) company name;

(b) company identification;

(c) company Entry description;

(d) effective Entry date;

(e) DFI account number;

(f) individual name/receiving company name;

33


(g) individual identification number/identification number;

(h) change code;

(i) original Entry trace number;

(j) original RDFI identification; and

(k) corrected data.

The Originator must make the changes specified in the NOC or corrected NOC within six Banking Days of receipt of the NOC information or prior to initiating another Entry to the Receiver’s account, whichever is later.

In the case of CIE and credit WEB Entries, the ODFI or the Third-Party Service Provider (rather than the consumer Originator) must make the changes specified in the NOC.

ARTICLE EIGHT

Definitions of Terms Used in These Rules

SECTION 8.22 “ Customer Initiated Entry” or “CIE Entry” or “CIE”a credit Entry initiated by or on behalf of the holder of a Consumer Account to the account of a Receiver.

a credit Entry initiated by or on behalf of the holder of a Consumer Account to the Non-Consumer account of a Receiver.

SECTION 8.48 “ Internet-Initiated/Mobile Entry” or “WEB Entry” or “WEB” 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.

1) a debit Entry initiated by an Originator to a Consumer Account of the Receiver based on (a) 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 (b) 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; or

2) a credit Entry initiated by or on behalf of the holder of a Consumer Account that is intended for the Consumer Account of a Receiver, regardless of whether the authorization of such Entry is communicated via the Internet or Wireless Network.

SECTION 8.64 “Person-to-Person Entry ” or “P2P Entry” (new section)a credit Entry initiated by or on behalf of a holder of a Consumer Account that is intended for a Consumer Account of a Receiver. A P2P Entry uses the Internet-Initiated/Mobile Entry (WEB) Standard Entry Class Code.

34


APPENDIX TWO

Specifications for Data Acceptance by ACH Operators

PART 2.5 Automatic Entry Detail Rejection Criteria R36 Return of Improper Credit Entry

• ACH credit Entries (with the exception of Reversals) are not permitted for use with the following Standard Entry Class Codes: ARC, BOC, POP, RCK, TEL, WEB, and XCK.

• ACH credit Entries (with the exception of Reversals) are not permitted for use with the following Standard Entry Class Codes: ARC, BOC, POP, RCK, TEL, and XCK.

APPENDIX THREE


SUBPART 3.2.2 Glossary of Data ElementsCompany 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.

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

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

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

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

WEB: For a Person-to-Person Entry, this field must contain a description that the Receiver would readily recognize as descriptive of a Person-to-Person Entry.

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

35


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

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

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

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

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

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

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

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

TRC: This field identifies the name of the keeper.

WEB: For a Person-to-Person Entry, this field contains the P2P service provider’s name; the P2P service provider is either the ODFI or a Third-Party Service Provider.

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)

Individual Identification Number: 15 Positions – Entry Detail Record – Optional (DNE, POS, PPD, TEL, WEB debit, Returns, dishonored Returns, contested dishonored Returns, COR, refused COR); Required (WEB credit); 22 Positions – Entry Detail Record – Mandatory (CIE, MTE)

36


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.

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.

WEB credit: For a Person-to-Person Entry, this field contains the name of the Originator of the P2P Entry for use by the RDFI on the periodic statement.

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


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



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

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

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

37



For Example:



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

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

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



#########*AMOUNT*$$$$.cc\





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


38








For Example:

22*12200004*3*123987654321*777777777*DOE*JOHN*0\

22*12200004*3*987654321123*876543210*ABCCOMPANY**B\










TERMINAL IDENTIFICATION CODE(MAXIMUM OF 6 CHARACTERS)*TERMINAL LOCATION (MAXIMUM OF 27 CHARACTERS)*TERMINAL CITY)MAXIMUM OF 15 CHARACTERS)

*TERMINAL STATE/FOREIGN COUNTRY (2 CHARACTERS)\

39


For example:




WEB: For a debit WEB Entry, Addenda Records contain payment related ANSI ASC X12 data segments or NACHA endorsed banking conventions (i.e., Tax Payment, Child Support, or Electronic Dealer Drafting). For a credit WEB Entry, this field contains 80 characters of payment related information.

APPENDIX E IGHT

Rule Compliance Audit Requirements

PART 8.4 Audit Requirements for ODFIs e. Verify that information relating to NOCs and Corrected NOCs is provided to each Originator or

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

e. Verify that information relating to NOCs and Corrected NOCs is provided to each Originator, or Third-Party Sender within two Banking Days of the Settlement Date of the NOC or Corrected NOC in accordance with Appendix Five (Notification of Change). For CIE and credit WEB Entries, verify that information relating to NOCs and Corrected NOCs is provided to any Third-Party Service Provider initiating such Entries on behalf of the consumer Originator. Verify that refused NOCs are Transmitted within fifteen (15) days of receipt of an NOC or corrected NOC. (Article Two, subsections 2.11.1 and 2.11.2)

40


Proof of Authorization for Non-Consumer Entries


SUMMARYThis Rule establishes an RDFI’s right to request, and an ODFI’s obligation to provide, proof of authorization for CCD, CTX, and IAT Entries to Non-Consumer Accounts.

BackgroundAs is standard for any ACH Entry, the NACHA Operating Rules require a business/Non-Consumer Receiver to explicitly authorize an ACH Entry to its account. Traditionally, business-to-business Entries arose out of trading partner relationships. This is reflected in the Rules requirement that the Receiver enter into an agreement with the Originator under which the Receiver has agreed to be bound to the NACHA Operating Rules. The terms of the authorization for ACH Entries between trading partners are typically included within the agreement between Originator and Receiver, and therefore are not further specified within the Rules. The Rules do not prescribe any specific manner of authorization/agreement (i.e., written v. oral), nor do they establish any minimum criteria for defining a valid authorization from a business Receiver.

ACH participants have expressed concern that under the current Rules, an RDFI is not permitted to request from the ODFI, and the ODFI is not required to provide, proof of authorization for business Entries. More than half of the responses by RDFIs in a 2010 RFI survey indicated that their Non-Consumer customers, many of them small businesses, seek their assistance with unauthorized Entries past the allowable return time frame. RDFIs generally refer their business Receivers to the terms of the Receiver’s contract with its trading partner (the Originator) for resolution of any dispute over a specific Entry.

In some cases, however, the Receiver has no contractual or trading partner relationship with the Originator of a debit Entry. This is often the case with RDFIs’ small business customers, and also occurs in cases of unauthorized or perhaps fraudulent transactions. In these cases, the business Receiver has no trading partner agreement to which it would be able to refer for terms of the authorization or resolution of disputes; to obtain proof of authorization from the Originator, it would turn to the RDFI for assistance. As noted above, however, the RDFI has no right under the current Rules to request a copy of the authorization for a CCD or CTX Entry, or an Inbound IAT Entry to a Non-Consumer account. This limitation makes resolution of the issue challenging and frustrating for both Receiver and RDFI.

KEY COMPONENTS OF RULE AMENDMENTRDFI Request for Proof of Authorization – CCD, CTX, and IAT Entries to Non-Consumer AccountsThis Rule permits an RDFI to request proof of a Non-Consumer Receiver’s authorization for a CCD, CTX, or an Inbound IAT Entry to a Non-Consumer Account. Specifically, an RDFI may request, in writing, that an ODFI provide evidence of authorization for any Entry, subject to the limitations contained in the Ruleson an Originator’s obligation to provide the record of authorization.

ODFI/Originator Requirement to Provide Proof of AuthorizationThis Rule requires the ODFI to provide the RDFI with proof of authorization for a CCD, CTX, or IAT Entry to a Non-Consumer Account. The ODFI must provide the required information to the RDFI at no charge within ten banking days of receiving a written request for such information from the RDFI. The Rule also requires the Originator to provide such proof of authorization to the ODFI for its use or for use by the RDFI.

41


The Rule provides two methods by which an ODFI can comply with the RDFI’s request for proof of authorization. The first is to provide an accurate record of the authorization. The second is to provide the Originator’s contact information that can be used for inquiries about authorization of Entries. At a minimum, this contact information must include (i) the Originator’s name, and (ii) the Originator’s phone number or email address for inquiries regarding authorization of Entries. An ODFI may utilize either method in responding to an RDFI’s request for proof of authorization. ODFIs may find this second method useful in cases where authorizations for Non-Consumer Entries are difficult or impossible to obtain because they are contained within extensive and proprietary trading partner agreements.

The Rule does not extend the return time frame for unauthorized Non-Consumer Entries, nor does it require an ODFI to accept a late Return if proof of authorization is not provided. This Rule does, however, facilitate the investigation and resolution of disputes over unauthorized Entries between entities with no relationship. The Rule does not alter any rules governing the return of unauthorized Entries bearing consumer SEC Codes that are received to a Non-Consumer account.

Privacy ConcernsSome ACH Participants may be concerned about whether the obligation to provide proof of authorization for an Entry to a Non-Consumer Account is consistent with applicable privacy laws. First, it should be noted that because these transactions relate to transfers between Non-Consumer accounts, most privacy laws will not apply.1 Second, even if such laws did apply, there are several standard exemptions that permit information sharing to protect against or prevent actual or potential fraud or unauthorized transactions, to resolve claims or disputes, or to process or service financial products and services requested or authorized by the consumer.2 Indeed, financial institutions already routinely share authorization information with respect to consumer accounts without issue.

IMPACT TO PARTICIPANTSRDFIs: The ability to request proof of authorization allows RDFIs to provide improved customer service to their business customers when dealing with claims of unauthorized transactions to their accounts. This Rule encourages greater communication between ODFIs and RDFIs when addressing disputes over these transactions.

ODFIs: ODFIs must establish policies and procedures to obtain either a copy of the Receiver’s authorization or the Originator’s contact information. The effective date of September 2014 allows ODFIs and Originators sufficient lead time to establish and implement any necessary policies and procedures and, if necessary, to make any modifications to ACH agreements.

Originators and Receivers: Receivers may request, and Originators must provide, proof of authorization or contact information for Entries to Non-Consumer Accounts, which should help to facilitate resolution of disputes over the validity of a particular transaction.


• Article Two, Subsection 2.3.3 (Agreement and Notice for Entries to Non-Consumer Accounts) – modifies the title of this subsection to reference the authorization of Entries.

1 Regulation P, 12 C.F.R. § 1016.1(b)(1) (Gramm-Leach-Bliley privacy applies to nonpublic personal information about individuals who obtain

fi nancial products or service primarily for personal, family or household purposes).2Regulation P, 12 C.F.R. § 1016.14(a)(1) and 1016.15(a)(2)(ii), (iii).

42


• Article Two, Subsection 2.3.3.3 (Provision of the Record of Authorization) – creates a new subsection specific to proof of authorization for Entries to Non-Consumer accounts.

• Article Three, Subsection 3.1.4 (RDFI May Request Copy of Receiver’s Authorization of Entry from ODFI) – adds a cross reference to permit an RDFI to request proof of the authorization for a Non-Consumer debit Entry.

• Article Three, Subsection 3.4.1.1 (Rule Exception Regarding Copy of Receiver’s Authorization) – removes this subsection from the Rules, which excludes CCD and CTX from the copy requirement in Subsection 3.1.4.

• Article Three, Subsection 3.4.3.2 (Rule Exception for IAT Entries to Non-Consumer Accounts) – removes this subsection from the Rules, which excludes IAT Entries to Non-Consumer accounts from the copy requirement in Subsection 3.1.4.


• • • •

As approved March 7, 2013, effective September 19, 2014, the Rules are modified as follows for the rule changes specific to Proof of Authorization for Entries to Non-Consumer Accounts.

ARTICLE TWO


SUBSECTION 2.3.3 Agreement and Notice for Entries to Non-Consumer Accounts SUBSECTION 2.3.3 Agreement, Notice, and Authorization for Entries to Non-Consumer AccountsSubsection 2.3.3.3 – Provision of the Record of Authorization (New Subsection)For a CCD, CTX, or Inbound IAT Entry to a Non-Consumer Account:

(a) Upon receipt of an RDFI’s written request for evidence of authorization of the Entry, the ODFI must provide either (1) an accurate record evidencing the Receiver’s authorization, or (2) the contact information for the Originator that, at a minimum, includes (i) the Originator’s name, and (ii) the Originator’s phone number or email address for inquiries regarding authorization of Entries. This record of authorization or contact information must be provided to the RDFI within ten Banking Days of receipt of the request without charge.

(b) At the request of its ODFI, the Originator must provide either (1) an accurate record evidencing the Receiver’s authorization, or (2) contact information for the Originator that, at a minimum, includes (i) the Originator’s name, and (ii) the Originator’s phone number or email address for inquiries regarding authorization of Entries. The Originator must provide the record or information to the ODFI for its use or for the use of an RDFI requesting the information in such time and manner as to enable the ODFI to deliver the information to the requesting RDFI within ten Banking Days of the RDFI’s request.

43


ARTICLE THREE


SUBSECTION 3.1.4 RDFI May Request Copy of Receiver’s Authorization of Entry from ODFI An RDFI may request, in writing, that an ODFI provide a copy of the Receiver’s authorization for any Entry, subject to the limitations contained in these Rules on an Originator’s obligation to retain and provide a copy of a Receiver’s authorization for an Entry (see Subsection 2.3.2.5 – Retention and Provision of the Record of Authorization). This subsection does not apply to credit Entries for which both the Originator and Receiver are natural persons.

An RDFI may request, in writing, that an ODFI provide a copy of the Receiver’s authorization for any Entry, subject to the limitations contained in these Rules on an Originator’s obligation to retain and provide a copy of a Receiver’s authorization for an Entry (see Subsection 2.3.2.5 – Retention and Provision of the Record of Authorization, and Subsection 2.3.3.3 – Provision of the Record of Authorization). This subsection 3.1.4 does not apply to credit Entries for which both the Originator and Receiver are natural persons.

SUBSECTION 3.4.1.1 Rule Exception Regarding Copy of Receiver’s Authorization The requirements of Subsection 3.1.4 (RDFI May Request Copy of Receiver’s Authorization of Entry from ODFI) do not apply to CCD and CTX Entries. (Effective September 19, 2014, this subsection will be deleted from the Rules.)

SUBSECTION 3.4.3.2 Rule Exception for IAT Entries to Non-Consumer Accounts The requirements of Subsection 3.1.4 (RDFI May Request Copy of Receiver’s Authorization of Entry from ODFI) do not apply to IAT Entries to non-Consumer Accounts. (Effective September 19, 2014, this subsection will be deleted from the Rules.)

44


Dishonored Returns and Contested Dishonored Returns Related to an Unintended Credit to a Receiver


SUMMARYThis Rule provides an Originator/ODFI with an additional mechanism to resolve, via the automated return process, situations in which use of the Reversal process has resulted in, or not resolved, an unintended credit to the Receiver.

An unintended credit to the Receiver may be caused by either of the following conditions:

(1) A debit Erroneous Entry and a subsequent credit Reversing Entry are both transmitted to the Receiver’s account. The erroneous debit is returned, but the reversing credit is posted and made available to the Receiver.

(2) A credit Erroneous Entry and a subsequent debit Reversing Entry are both transmitted to the Receiver’s account. The erroneous credit is posted and made available to the Receiver, but the reversing debit is returned.

KEY COMPONENTS OF RULE AMENDMENTODFI’s Right to Dishonor a Debit Return that Causes an Unintended Credit to the ReceiverThe Rule establishes the right of an ODFI to dishonor the Return of a debit Erroneous Entry if the Return Entry results in an unintended credit to the Receiver because (1) the Return Entry relates to a debit Erroneous Entry, (2) the ODFI has already originated a credit Reversing Entry to correct the Erroneous Entry, and (3) the ODFI has not received a Return of that credit Reversing Entry.

Similarly under the Rule, an ODFI may dishonor the Return of a debit Reversing Entry if the Return Entry results in an unintended credit to the Receiver because (1) the Return Entry relates to a debit Reversing Entry that was intended to correct a credit Erroneous Entry, and (2) the ODFI has not received a Return of that credit Erroneous Entry.

The Rule defines a new dishonored Return Reason Code (R62 – Return of Erroneous or Reversing Debit) for this purpose.

ODFI Warranties for Dishonored Return Relating to ReversalsThis Rule requires an ODFI dishonoring a debit Return Entry under either of these conditions to warrant that it originated a Reversal in an effort to correct the original erroneous transaction and therefore is dishonoring the Return of the debit Erroneous Entry or the debit Reversing Entry, either of which causes an unintended credit to the Receiver.

RDFI’s Right to Contest a Dishonored Return Involving an Unintended Credit to ReceiverThe Rule also establishes the right of an RDFI to contest this type of dishonored Return if either of the following conditions exists:

(1) the RDFI returned both the Erroneous Entry and the related Reversal; or

(2) the RDFI is unable to recover the funds from the Receiver.

45


The Rule defines a new contested dishonored Return Reason Code (R77 – Non-Acceptance of R62 Dishonored Return) for this purpose.

IMPACT TO PARTICIPANTSOriginators/ODFIs: This rule change benefits the ODFI/Originator by providing an automated means to resolve situations in which use of the Reversal process has resulted in or not resolved an unintended credit to the Receiver.

RDFIs: The addition of a contested dishonored Return Reason Code (R77 – Non-Acceptance of R62 Dishonored Return) provides the RDFI with the ability to contest a dishonored Return coded as R62 (Return of Erroneous or Reversing Debit) if it is unable to recover the funds from the Receiver or if it has returned both the Erroneous Entry and the corresponding Reversing Entry.


• Article Two, Subsection 2.12.5.1 (Dishonor of Return Entries) – adds language stating that an ODFI may dishonor a Returned Entry if the Reversal process resulted in, or failed to correct, an unintended credit to the Receiver.

• Article Two, Subsection 2.12.5.2 (Specific Warranties for Dishonored Return Relating to Reversals) – creates a new subsection to address the ODFI’s warranty specific to a dishonored Return relating to use of the Reversal process.

• Article Three, Subsection 3.8.5.2 (RDFI May Contest Dishonored Returns) – adds language stating the RDFI may Transmit a contested dishonored Return Entry if it has returned both the Erroneous Entry and the Reversing Entry, or if the RDFI is unable to recover the funds from the Receiver.

• Appendix Four, Part 4.2 (Table of Return Reason Codes) – adds new dishonored Return Reason Code (R62 – Return of Erroneous or Reversing Debit) and new contested dishonored code (R77 – Non-Acceptance of R62 Dishonored Return) to the Table of Return Codes.


• • • •

As approved March 7, 2013, effective March 20, 2015, the Rules are modified as follows for the rule changes specific to Dishonored Returns and Contested Dishonored Returns Related to an Unintended Credit to a Receiver.

46


ARTICLE TWO


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

(a) the RDFI failed to return the Entry within the time limits established by these Rules;

(b) information in one or more of the following fields of the Return Entry is incorrect or missing:

(i) DFI Account Number

(ii) Original Entry Trace Number

(iii) Dollar Amount

(iv) Individual Identification Number/Identification Number

(v) Transaction Code

(vi) Company Identification Number

(vii) Effective Entry Date

(c) the Return Entry was misrouted;

(d) the Return Entry was a duplicate;

(e) the Return Entry is coded as the Return of an Erroneous Entry at the request of the ODFI, as permitted by Subsection 2.12.2 (ODFI Request for Return), but the ODFI did not make such a request;

(f) the Return Entry is coded as a permissible Return Entry, as permitted by Subsection 3.8.3.5 (Late Return Entries for CCD or CTX Entries with ODFI Agreement), but the ODFI did not agree to accept the Return Entry;

(g) the Return Entry would result in an unintended credit to the Receiver because (1) the Return Entry relates to a debit Erroneous Entry, (2) the ODFI has already originated a credit Reversing Entry to correct the Erroneous Entry, and (3) the ODFI has not received a Return of that credit Reversing Entry; or

(h) the Return Entry would result in an unintended credit to the Receiver because (1) the Return Entry relates to a debit Reversing Entry that was intended to correct a credit Erroneous Entry, and (2) the ODFI has not received a Return of that credit Erroneous Entry.

To dishonor a Return Entry, the ODFI must Transmit a dishonored Return Entry complying with Appendix Four (Return Entries) to its ACH Operator within five Banking Days after the Settlement Date of the Return Entry.

47


Subsection 2.12.5.2 – Specific Warranties for Dishonored Return Relating to Reversals (New Subsection) (a) An ODFI dishonoring the Return of a debit Erroneous Entry in accordance with subsection

2.12.5.1(g) (Dishonor of Return by ODFI) warrants that the ODFI Transmitted a credit Reversing Entry to correct such debit Erroneous Entry and that the ODFI has not received a Return of that Reversing Entry from the RDFI.

(b) An ODFI dishonoring the Return of a debit Reversing Entry in accordance with subsection 2.12.5.1 (h) (Dishonor of Return by ODFI) warrants that such Reversing Entry was intended to correct a corresponding credit Erroneous Entry and that the ODFI has not received a Return of the credit Erroneous Entry from the RDFI.

ARTICLE THREE


SUBSECTION 3.8.5.2 RDFI May Contest Dishonored Returns An RDFI may Transmit a contested dishonored Return Entry that corresponds to the reason for the dishonored Return Entry if:

(a) the original Return Entry was, in fact, returned within the time limits established by these Rules;

(b) the original Return Entry was not a duplicate Entry;

(c) the original Return Entry was complete and contained no errors;

(d) the dishonored Return Entry was misrouted or untimely;

(e) the dishonored Return Entry relates to an Erroneous Entry or a Related Reversing Entry, both of which were previously returned by the RDFI; or

(f) the funds relating to the R62 dishonored Return Entry are not recoverable from the Receiver (for use ONLY with dishonored Returns R62 – Return of Erroneous or Reversing Debit).

The RDFI must Transmit a contested dishonored Return Entry to the ACH Operator within two Banking Days after the Settlement Date of the dishonored Return Entry and must ensure the contested dishonored Return Entry otherwise complies with the requirements of Appendix Four (Return Entries).

48


PAR

T 4.

2 Ta

ble

of R

etur

n R

easo

n C

odes

(con

tinue

d)

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

CO

DES

TO

BE

USE

D B

Y TH

E O

DFI

FO

R D

ISH

ON

OR

ED R

ETU

RN

EN

TRIE

S

R61

Mis

rout

ed

Retu

rn

The

finan

cial in

stitu

tion

prep

arin

g th

e Re

turn

Ent

ry

(the

RDFI

of t

he o

rigin

al

Entry

) has

pla

ced

the

inco

rrect

Rou

ting

Num

ber

in th

e Re

ceivi

ng D

FI

Iden

tifica

tion

field

.

ODF

I Di

shon

ored

Re

turn

May

be

used

fo

r all E

ntrie

s ex

cept

IAT.

Cons

umer

or

Non-

Cons

umer

Th

e O

DFI m

ust

trans

mit

a di

shon

ored

Ret

urn

Entry

to it

s ACH

O

pera

tor w

ithin

five

Ba

nkin

g Da

ys a

fter

the

Settl

emen

t Dat

e of

the

Retu

rn E

ntry

.

No

Artic

le T

wo, S

ubse

ctio

n 2.

12.5

.1 -

Dish

onor

of R

etur

n by

ODF

I.

May

be

used

for a

ll Ent

ries

exce

pt IA

T.

R62

Ret

urn

of

Erro

neo

us

or

Rev

ersi

ng

Deb

it

The

Ori

gin

ator

’s/O

DFI

’s

use

of

the

reve

rsal

pro

cess

ha

s re

sulte

d in

, or

faile

d to

co

rrec

t, an

un

inte

nde

d cr

edit

to

the

Rec

eive

r.

OD

FID

isho

nor

ed

Ret

urn

May

be

use

d fo

r al

l En

trie

s ex

cept

IAT

.

Con

sum

er o

r N

on-C

onsu

mer

The

OD

FI m

ust

tr

ansm

it a

di

shon

ored

Ret

urn

En

try

to it

s AC

H

Ope

rato

r w

ithi

n fi

ve

Ban

kin

g D

ays

afte

r th

e Se

ttlem

ent D

ate

of th

e R

etu

rn E

ntr

y.

No

Art

icle

Tw

o, S

ubs

ecti

on

2.12

.5.1

- D

isho

nor

of

Ret

urn

by

OD

FI.

Art

icle

Tw

o, S

ubs

ecti

on

2.12

.5.2

- Sp

ecif

ic W

arra

nti

es

for

Dis

hon

ored

Ret

urn

R

elat

ing

to R

ever

sals

.

May

be

use

d fo

r al

l En

trie

s ex

cept

IAT

.

Usa

ge is

lim

ited

to th

e fo

llow

ing

two

Rev

ersa

l sce

nar

ios:

(1)

A d

ebit

Err

oneo

us

Entr

y an

d a

subs

equ

ent c

redi

t Rev

ersi

ng

En

try

are

both

tran

smit

ted

to

the

Rec

eive

r’s

acco

un

t. Th

e de

bit

Erro

neo

us

Entr

y is

ret

urn

ed

but t

he c

redi

t Rev

ersi

ng

Entr

y is

pos

ted

and

mad

e av

aila

ble

to

the

Rec

eive

r.

(2)

A c

redi

t Err

oneo

us

Entr

y an

d a

subs

equ

ent d

ebit

R

ever

sin

g E

ntr

y ar

e bo

th

tran

smit

ted

to th

e R

ecei

ver’

s ac

cou

nt.

The

cred

it E

rron

eou

s En

try

is p

oste

d an

d m

ade

avai

labl

e to

the

Rec

eive

r, b

ut

the

debi

t Rev

ersi

ng

Entr

y is

re

turn

ed.

* 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.

49


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

R77

Non

-Acc

epta

nce

of

R62

D

isho

nor

ed

Ret

urn

The

RD

FI r

etu

rned

bot

h th

e Er

ron

eou

s En

try

and

the

rela

ted

Rev

ersi

ng

Entr

y, o

r th

e fu

nds

rel

atin

g to

the

R62

dis

hon

ored

Ret

urn

are

n

ot r

ecov

erab

le f

rom

the

Rec

eive

r.

RD

FI

Con

test

ed

Dis

hon

ored

R

etu

rn

May

be

use

d fo

r al

l En

trie

s ex

cept

IAT

.

Con

sum

er o

r N

on-C

onsu

mer

Th

e co

nte

sted

di

shon

ored

Ret

urn

En

try

mu

st b

e tr

ansm

itte

d to

th

e AC

H O

pera

tor

wit

hin

two

Ban

kin

g D

ays

afte

r th

e Se

ttlem

ent D

ate

of th

e di

shon

ored

R

etu

rn E

ntr

y.

No

Art

icle

Thr

ee, S

ubs

ecti

on

3.8.

5.2

- RD

FI M

ay C

onte

st

Dis

hon

ored

Ret

urn

s

May

be

use

d fo

r al

l En

trie

s ex

cept

IAT

.

For

use

by

the

RD

FI in

res

pon

se

to th

e re

ceip

t of

Dis

hon

ored

R

etu

rn C

ode

R62

- R

etu

rn o

f Er

ron

eou

s or

Rev

ersi

ng

Deb

it.

For

use

on

ly w

hen

the

RD

FI h

as

retu

rned

bot

h th

e E

rron

eou

s En

try

and

the

subs

equ

ent

Rev

ersi

ng

Entr

y, o

r th

e R

DFI

is

un

able

to r

ecov

er th

e fu

nds

re

lati

ng

to th

e R

62 d

isho

nor

ed

Ret

urn

fro

m th

e R

ecei

ver.

* 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

(con

tinue

d)

50


Supplement #1-2013 to the NACHA Operating Guidelines

Supplement #1-2013 contains updated guidance related to ACH data security that impacts two chapters of the NACHA Operating Guidelines (Guidelines). The first part of the guidance completely replaces the section entitled “ACH Data Security Requirements” found in Chapter 4 – General Rules of the 2013 Guidelines. The second part replaces Chapter 7 – ODFI Risk Management in its entirety.

51


CHAPTER 4

General Rules

ACH DATA SECURITY REQUIREMENTSProtection of Sensitive Data and Access ControlsAs of September 20, 2013, the rules for ACH data security require all non-consumer Originators, Participating DFIs (ODFIs and RDFIs), Third-Party Service Providers, and Third-Party Senders to comply with specific security requirements with respect to the handling and storage of Protected Information. The security requirements do not apply directly to consumers, who can be Originators of CIE entries; however, such security requirements will apply to parties originating CIE Entries on behalf of consumers (i.e., the consumer’s financial institution or a Third-Party Sender).

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

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

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

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

Protected Information is defined as:

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

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

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

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

52


Self-AssessmentEffective September 20, 2013, each Participating DFI, Third-Party Service Provider, and Third-Party Sender must verify, as part of the requirements for an annual ACH Rules Compliance Audit, that it has established, implemented, and updated the data security policies, procedures, and systems required by the Rules.

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

Verification of Third-Party Senders and OriginatorsAs of September 20, 2013, an ODFI must use a commercially reasonable method to determine the identity of each non-consumer Originator or Third-Party Sender with which the ODFI enters into an Origination Agreement, at the time the agreement is created. The commercially reasonable standard is discussed in more detail later in this chapter.

Transmission of Data Via Unsecured Electronic NetworksFor all ACH transactions that involve the exchange or transmission of banking information (which includes, but is not limited to, an entry, entry data, a routing number, an account number, and a PIN or other identification symbol) via an Unsecured Electronic Network, the NACHA Operating Rules require that such banking information be either:

1. encrypted using a commercially reasonable security technology that, at a minimum, is equivalent to 128-bit RC4 encryption technology, or

2. transmitted via a secure session that utilizes a commercially reasonable security technology that provides a level of security that, at a minimum, is equivalent to 128-bit RC4 encryption technology.

For purposes of the NACHA Operating Rules and the ACH Network, an Unsecure Electronic Network is a network, public or private, that:

1. is not located entirely within a single, contiguous, physical facility; and

2. either (a) transmits data via circuits that are not dedicated to communication between two end-points for the duration of the communication, or (b) transmits data via wireless technology (excluding a communication that begins and ends with a wireline connection, but that is routed by a telecommunications provider for a portion of the connection over a wireless system).

For clarity, the Internet is an Unsecure Electronic Network, even though secure transmissions may be made over that otherwise unsecure network.

A secure Internet session is one that is typically indicated by the secure access symbol on the bottom menu bar of the browser (e.g., a padlock). For security purposes, a secure Internet session will generally expire after a certain period of inactivity, at which time the user will be required to reenter the login credentials initially used to enter the secure Internet session. Currently, 128-bit RC4 encryption technology is the standard for financial transactions and is considered commercially reasonable. If technological advancements drive the commercially reasonable standard to change, Originators should comply with the new standard.

Figure 4-1 on the following page depicts the concept of a secure Internet session.

53


These encryption requirements must be employed prior to the key-entry and through the transmission of any banking information exchanged over such an Unsecured Electronic Network between:

1. an Originator and a Receiver;

2. an Originator and an ODFI;

3. an ODFI and an ACH Operator;

4. an ACH Operator and an RDFI; and

5. an Originator, ODFI, RDFI, or ACH Operator and a Third-Party Service Provider.

Transmissions of banking information over an Unsecured Electronic Network by means of voice or keypad inputs from a wireline or wireless telephone to a live operator or voice response unit are not subject to this data security requirement. An application in which the Originator obtains information from the Receiver by another means (such as the telephone) and then key enters the information via the Internet is, for example, subject to these data security requirements. However, information delivered via telephone line, such as a leased line, or dialed into a financial institution’s modem pool is not subject to this requirement.

54


COMMERCIALLY REASONABLE STANDARDA commercially reasonable system, technology, practice, or procedure is one that corresponds to commonly-accepted commercial practices among commonly situated parties conducting similar types of transactions. The concept of commercial reasonableness means that a party, given the facts of a specific transaction, acted in a way that other similar parties would have acted. Whether a party has fulfilled its obligations to perform in a commercially reasonable manner is determined based on an evaluation of the circumstances.

Accordingly, what constitutes a commercially reasonable system, technology, practice or procedure may change over time. For example, as new technology becomes available or costs of certain technologies or procedures decrease, new standards of commercial reasonableness may evolve. Therefore, ACH participants need to work together to ensure continued compliance. The person challenging the use of a particular system, technology, practice or procedure has the burden of establishing that the system, technology, practice or procedure employed by a particular party was not commercially reasonable.

55


CHAPTER 7

ODFI Risk Management

In addition to the risk assessment required of all Participating DFIs, the NACHA Operating Rules have further requirements for ODFIs. Specifically, the Rules mandate ODFIs to perform due diligence to ensure that each Originator or Third-Party Sender transmitting or sending entries to the ODFI on behalf of an Originator or another Third-Party Sender has the ability to perform its obligations in compliance with the Rules. The ODFI must:

• ensure that it has implemented procedures to assess the nature of the Originator’s or Third-Party Sender’s ACH activity and the risks it presents;

• establish, implement, and periodically review an exposure limit for the Originator or Third-Party Sender; and

• establish and implement procedures to monitor the Originator’s or Third-Party Sender’s origination and return activity across multiple Settlement Dates, enforce restrictions on the types of ACH transactions that may be originated, and enforce the exposure limit.

ODFIs must ensure that appropriate risk management practices are in place for Originators or Third-Party Service Providers that act as Sending Points and transmit entries directly to the ACH Operator, commonly referred to as direct access. It is appropriate to include language covering risk management in the agreement between the Originator and the Third-Party Service Provider.

KNOW YOUR CUSTOMERIn an environment where unauthorized transactions or transactions that arise from deceptive business practices are being attempted over the ACH Network, financial institutions must take proactive steps to safeguard their financial assets, as well as their reputations. One fundamental step toward this goal is to ensure that ODFIs know their customers. To protect themselves against financial loss, ODFIs must ensure that their Originators are credit-worthy and engage in reputable business practices.

Although ODFIs may restrict or refuse ACH services to some organizations directly, they must be aware that businesses engaged in questionable business practices may be originating ACH payments through Third-Party Service Providers that have authorization to use the ODFI’s routing number to transmit ACH entries directly to the ACH Operator (i.e., direct access). In such cases, the ODFI is exposed to the same financial and reputational risk and liability, but may be unaware of or have no contractual agreements with the companies on whose behalf they are originating entries. ODFIs must ensure that they have thoroughly evaluated the risks and potential liabilities of granting direct access to the ACH Operator before giving any customer such capabilities.

Chapter 8 of these Guidelines discusses direct access in detail.

ACH DATA SECURITY REQUIREMENTSEffective September 20, 2013, each ODFI must comply with security requirements aimed at protecting the security and integrity of certain ACH data throughout its life cycle. More information about these requirements, which govern most ACH participants, can be found in Chapter 4 – General Rules of these Guidelines.

56


In addition to its own compliance with the ACH security requirements, an ODFI is responsible for the compliance with these provisions by its Originators, Third-Party Senders, and other Third-Party Service Providers.

The Rules do not establish specific oversight requirements for ODFIs attempting to monitor and enforce the compliance with these provisions by their Originators, Third-Party Senders and other Third-Party Service Providers. Instead, as with all other provisions of the Rules, there is a requirement that ODFIs perform due diligence with respect to their Originators and Third-Party Senders that is sufficient to form a reasonable belief that the Originator or Third-Party Sender has the capacity to perform its obligations in conformance with the Rules. Such due diligence should be risk-based since the threats to the security of confidential ACH information vary depending on the circumstances under which such information may be gathered and used. For example, the risks posed by a small business Originator that uses the ACH principally to initiate ACH credits for its internal direct deposit of payroll are very different from the risks posed by an Originator that is an Internet-based bill payment services provider handling payments for thousands individuals. These risks also may shift over time with changing patterns of fraud and ACH usage. Similarly, although there is no requirement in the Rules that an ODFI audit its Originators’ compliance with the Rules, the Rules provide ODFIs with the express right to perform such an audit if warranted. Thus, the Rules leave to each ODFI the flexibility to determine the best approach to oversight of the parties for which it provides access to the ACH network.

VOLUNTARY AVAILABILITY EXCEPTION FOR RDFIsODFIs need to be aware that RDFIs can take advantage of a voluntary exception from the existing funds availability requirements prescribed in the Rules when it reasonably suspects that an ACH credit is not authorized. This exception allows an RDFI additional time to investigate a suspicious credit prior to making funds available to the Receiver. The additional time increases the likelihood that unauthorized credit entries could be identified and the associated funds could be recovered before they are withdrawn. An RDFI also could, but is not obligated to, use this exception to respond to a request from an ODFI to investigate or return the funds related to a credit entry. ODFIs and RDFIs can work together, on a voluntary basis, to investigate a possible case of an unauthorized credit transaction. (Note: RDFIs must still comply with Regulation CC availability requirements, unless an exception to the requirements applies.)

DATA PASSINGThe Restore Online Shoppers’ Confidence Act prohibits a merchant from initiating an Internet transaction unless the merchant has obtained certain authorization information, including account number and consumer’s name and address, directly from the consumer. This law also prohibits a merchant from disclosing a customer’s account number and other billing information to another merchant for use in an Internet-based sale.

Effective March 15, 2013, the NACHA Operating Rules will be modified to protect customers from such potentially confusing practices. NACHA will adopt a rule that is similar to those currently in effect in major card brand rules. This rule will be broader in scope than the requirements of The Restore Online Shoppers’ Confidence Act in that it is not limited to Internet transactions.

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

57


EXPOSURE LIMITS It is insufficient for an ODFI to just establish an exposure limit on its Originator’s or Third-Party Sender’s origination. The ODFI must ensure that it can actively measure exposure limits when processing ACH credit and debit entries on behalf of its customers. The limit must reflect ACH processing activity and be monitored as part of daily operations. The ODFI must ensure that it has established and implemented procedures for acting upon files that exceed exposure limits and for handling exception situations. The ODFI should be sure that its procedures for collecting and monitoring exposure limit information do not impede normal file processing. ODFIs should review exposure limits on a periodic basis and modify them as needed.

OFAC REGULATIONS The U.S. Treasury Department’s Office of Foreign Assets Control (OFAC) administers economic sanctions and embargo programs that require that assets and transactions involving interests of target countries, target country nationals, and other specifically identified companies and individuals be frozen. For purposes of OFAC compliance, these entities are called “ blocked parties” and OFAC maintains and regularly updates a master list of “Specially Designated Nationals and Blocked Persons” (“SDN List”) identifying known blocked persons. All of the programs involve declarations of national emergency by the President of the United States.

Like other payment mechanisms, the ACH Network is subject to the requirement to comply with OFAC regulations. All U.S. citizens and permanent resident aliens, companies located in the U.S., overseas branches of U.S. companies, and, in some cases, overseas subsidiaries of U.S. companies fall under OFAC jurisdiction. In terms of the ACH Network, this means that all U.S. ACH participants, including Originators, ODFIs, RDFIs, and Receivers need to be aware that they may be held accountable for sanctions violations and must understand their compliance obligations.

Chapter 3 of these Guidelines contains detailed information relating to OFAC Regulations and their impact on ODFIs.

RULES ENFORCEMENT The National System of Fines included in the NACHA Operating Rules is intended to maintain the quality of ACH services and to help ensure compliance by Participating DFIs with the requirements of the NACHA Operating Rules. A Participating DFI or an ACH Operator that is a party to an ACH transaction may utilize the rules enforcement process to address any violation of the provisions of the NACHA Operating Rules.

For complete information on the requirements governing the National System of Fines and the submission of a Report of Possible ACH Rules Violation, see Chapter 51 on the National System of Fines in these Guidelines.

ODFI REPORTING REQUIREMENTSIf NACHA believes that the return rate for unauthorized debit entries exceeds one percent (1%) for any Originator(s) or Third-Party Sender(s) for which an ODFI originates entries, then NACHA may send a written request to the ODFI’s Chief Operating Officer for certain information as set forth in the Rules. The return reason codes related to the return of unauthorized entries are R05, R07, R10, R29, and R51. The ODFI has ten (10) banking days from receipt of the written request to respond with specified data and an explanation either demonstrating that its Originator or Third Party Sender did not exceed the one percent (1%) threshold or explaining why it exceeded the threshold. If the ODFI confirms the Originator’s return rate exceeded the threshold, the Rules require the ODFI to provide specific information regarding how the institution will come into compliance with this rules provision The failure to provide required

58


information, the failure to reduce the return rate for unauthorized debit entries below one percent (1%) for any Originator(s) or Third-Party Sender(s), or the recurrence of a breach of the one percent (1%) threshold may result in enforcement action under the Rules.

nacha operating rules · 2018. 3. 22. · 2013 nacha operating rules and guidelines . may 1, 2013 ....

Documents