Nacha Rules Changes

2021 - March: Supplementing Fraud Detection Standards for WEB Debits
Effective on March 19, 2021, the rule change is intended to enhance quality and improve risk management within the ACH Network by supplementing the fraud detection standard for Internet-initiated (WEB) debits. ACH originators of WEB debit entries have always been required to use a “commercially reasonable fraudulent transaction detection system” to screen WEB debits for fraud. The existing screening requirement is supplemented by this change to make it explicit that “account validation” is part of a “commercially reasonable fraudulent detection system”. The supplement requirement would apply to the first use of an account number or changes to the existing account. 

2021 - March: Expanding Same Day ACH to Later Deadline
The effective date of a new, third Same Day ACH processing window is March 19, 2021. RDFIs must make funds available for SDA credits in this new SDA processing window no later than the end of its processing day.

2020 - June: Supplementing Data Security Requirements for Large Originators, Third-Party Service Providers (TPSPs) and Third-Party Senders (TPSs)
The Supplementing Data Security Requirements originally scheduled for a June 2020 implementation has been moved to a June 2021 implementation. 

2020 - April: New R11 Will Differentiate Unauthorized Return Reasons
Effective on April 1, 2020, the Rule to better differentiate unauthorized return reasons goes into effect. Up until this time, return reason R10 with the description of “Unauthorized” has been a catch-all for various types of ACH debit returns including those when the originator has made an error. R11, a re-purposed reason will going forward have the description of “Customer Advises Entry Not In Accordance with the Terms of the Authorization”. R11 will be used to return an ACH entry when a receiving financial institution receives a claim from their account holder that the ACH entry has an error such as the wrong date or the incorrect amount. R11 will have the same 60-day extended return time frame and requirement for a Written Statement as with R10 and the sender of the ACH debit will not be required to obtain a new authorization if the error is corrected. R11 returns will be covered by the Unauthorized Entry Return Rate reporting requirement as with R10 returns. The Unauthorized Entry Fee for R11 returns will take effect on April 1, 2021. 

2020 - March: Same Day ACH per Transaction Increases to $100,000
Effective on March 20, 2020, the per-transaction dollar limit for Same Day ACH transactions will increase from $25,000 to $100,000. Both Same Day ACH credits and Same Day ACH debits will be eligible for same day processing up to $100,000 per transaction. 

2019 - September: Providing Faster Funds Availability for Same Day and Next Day ACH Credits
Effective September 20, 2019, this new rule increases the speed of funds availability for certain Same Day ACH and next-day ACH credits.  There are two changes with this rule, first, funds from Same Day ACH credits processed in the existing, first processing window will be made available to receivers by 1:30 p.m. RDFI local time.  Secondly, funds from non-Same Day ACH credits will be available by 9:00 a.m. RDFI local time on the settlement day, if the RDFI had them by 5:00 p.m. on the previous day.  This applies the existing “PPD rule” to all ACH credits.

2019 - June: RDFIs (Receiving Depository Financial Institutions) have Option to Return for Questionable Transaction
Effective June 21, 2019, this change allows RDFIs, but it is not required of RDFIs, to indicate within a return that the original transaction was questionable or part of anomalous activity. RDFIs electing to return under this circumstance would use R17 as the return reason code and would indicate “QUESTIONABLE” in the Addenda information field.

2019 - January: ACH Rules Compliance Audit Requirements Consolidated in Article One
Previously the general obligation for participating DFIs (Depository Financial Institutions) and certain Third-Party Service Providers (TPSPs) and Third-Party Senders (TPSs) to conduct an audit was within Article One, Section 1.2.2. and the details pertaining to the audit obligations were located within Appendix Eight (Rule Compliance Audit Requirements) of the Rules.  Effective January 1, 2019, the requirement to conduct an annual compliance audit is consolidated within Article One of the Rules.  The prescribed list of topics that had been in Appendix Eight previously in the Rules is now part of the Guidelines as guidance. 

2018 - March: Same Day ACH Phase 3
Effective March 16, 2019, the final phase of the initial Same Day ACH implements the rule that funds availability for Same Day ACH credits is by 5:00 p.m. local time of the receiving financial institution.

2017 - September: Same Day ACH Debits
Effective September 15, 2017, the National Automated Clearing House Association (NACHA), the organization that governs the ACH network, will implement a rule change that allows the initiation of Same Day ACH debit payments of $25,000 or less, with funds available to the receiver by the end of the receiving financial institution’s processing day. Same Day ACH will be available for debits starting September 15, 2017. All ACH transaction types are eligible, except for International ACH Transactions (IATs).

NACHA’S Same Day ACH rollout began in September 2016 with the introduction of Same Day ACH for credit entries. Starting in 2018, receiving financial institutions must make Same Day ACH transactions funds available to the receiver by 5:00 pm local time.

2017 - September: Third Party Sender Registry
Effective September 29, 2017, the Third Party Sender registry is being created to improve the overall quality of the ACH Network and promote appropriate due diligence among Originating Depository Financial Institutions (ODFIs) processing for Third-Party Senders (TPS).

The new rule will require all ODFIs to register their TPS customers with NACHA, providing the following information regarding each TPS for which the ODFI provides ACH services. 

• TPS Name
• TPS Location (City, State)
• Routing Number
• Company ID(s)

After the initial registration, NACHA may request supplemental information about a TPS regarding any potential risk event. A risk event is defined as “cases in which NACHA believes that a TPS in the ACH network poses an escalated risk of (i) financial loss to one or more Participating (Depository Financial Institutions) DFIs, Receivers or Originators, (ii) violation of the (NACHA) Rules or Applicable Law, or (iii) excessive returns.”

For additional information regarding these rule changes, or to request a copy or access to the latest ACH Rules from PNC, please contact your Treasury Management representative.

2016 - October: Unauthorized Entry Fee
Effective October 3, 2016, to improve the overall quality of the ACH Network by reducing returns, NACHA is implementing a rule that applies to ACH debit transactions that are returned as “unauthorized” by the Receiver.

The rule introduces a fee of $4.50, assessed to the originating financial institution, for each ACH debit transaction that is returned as unauthorized. The fee will be passed to the receiving financial institution to compensate them for expenses related to servicing and returning the transaction for their customer. The rule applies to the following return reason codes:

• R05 – Unauthorized Debit to Consumer Account Using Corporate SEC Code
• R07 – Authorization Revoked by Customer
• R10 – Customer Advised Unauthorized, Improper, Ineligible or Incomplete Transaction
• R29 – Corporate Customer Advises Unauthorized
• R51 – Item Related to RCK Entry is Ineligible or RCK Entry is Improper

The fees for unauthorized debit returns as of October 3, 2016 would be applied to debits originated as early as August 1, 2016.  NACHA will evaluate the fee amount every three years.

Please Note: The fee is not applicable to International ACH Transactions (IATs).

2016 - September: Same Day ACH 
Effective September 23, 2016, the rule will enable the option to initiate same day ACH payments through new ACH Network functionality. This option is in addition to the existing ACH network processing capabilities. The rule will be implemented over three phases with Phase 1 beginning on September 23, 2016.

Phase 1 will support ACH credits only. All transaction types are eligible (except International ACH Transactions (IATs)) up to $25,000 per transaction. All receiving financial institutions must be able to receive same day ACH payments and make funds available to the receiver by the end of the receiving financial institution’s processing day in Phase 1.

There is an additional fee to originate Same Day ACH entries and no additional fee to receive Same Day ACH entries.2016 - September: Same Day ACH

2015 - September: Return Rate Changes
Effective September 18, 2015,

1. Current monthly unauthorized debit return rate threshold reduced from 1% to 0.5%

Your total number of ACH debit returns with Unauthorized Return Reason Codes should not exceed 0.5% of your total ACH debits originated.  Should you exceed the stated threshold, we may contact you to inquire on the reason for the high return rate. The following Return Reason Codes are considered unauthorized reason codes:

R05 - Unauthorized Debit to Consumer Account Using Corporate SEC Code
R07 - Authorization Revoked by Customer
R10 - Customer Advises Not Authorized
R29 - Corporate Customer Advises Not Authorized
R51 - Item is Ineligible

2. Established monthly ACH debit administrative return rate threshold of 3%

Your total number of ACH debit returns with Administrative Return Reason Codes should not exceed 3% of your total ACH debits originated.  Should you exceed the stated threshold, we may contact you to inquire on the reason for the high return rate. 

The following Return Reason Codes are considered Administrative Return Reason Codes:

R02 - Account Closed
R03 - No Acct/Unable to Locate Acct
R04 - Invalid Account Number

3. Established monthly overall ACH debit return rate threshold of 15%

Your total number of ACH debit returns for all Return Reason Codes should not exceed 15% of your total ACH debits originated.  Should you exceed the stated threshold, we may contact you to inquire on the reason for the high return rate.  All ACH debit returns regardless of Return Reason Code for all Standard Entry Class codes except RCK (Re-presented Check Entries) are considered for this calculation.

4. Re-initiation of ACH debits required to contain “RETRY PYMT” in the Company Entry Description field

If ACH debits that are returned unpaid with R01 – Insufficient Funds or R09 – Uncollected Funds Return Reason Codes and are subsequently re-presented for payment, the description “RETRY PYMT” is required to be included in the Company Entry Description field. If you currently originate debit re-presented files, you are required to update the Company Entry Description prior to submitting. Not updating the Company Entry Description may result in the RDFI returning the transaction with an R10 - Customer Advises Unauthorized, Improper, or Ineligible Return Reason Code.  If you have selected PNC’s “ACH Auto Debit Re-presentment” service feature, no action is required from you.  PNC will automatically change your Company Entry Description to include “RETRY PYMT.”

2015 - March: Removal of Notification of Change (C04 Change Code) and Rule Changes Related to Dishonored Returns 
Effective March 20, 2015, removal of Notification of Change - C04 Change Code (Incorrect Individual Name/Receiving Company Name)

Previously, Receiving Depository Financial Institutions (RDFIs) would send a Notification of Change – C04 to request a correction to the Receiver’s name on future ACH transactions. This sometimes created challenges for Originators, ODFIs and RDFIs. An example was when the Biller (Originator) could not make the requested name change due to contractual or other reasons while the Original Depository Financial Institution faced NACHA violations for not updating the name. To eliminate this risk the C04 code will be removed as a valid change code.

Impact to ODFIs / Originators

If you are an ACH Originator and the Receiver’s name on the ACH transaction and Receiver’s name at the RDFI do not match, rely on contracts and records to properly identify the name of the Receiver being credited or debited, without relying on a Notification of Change (NOC) from the RDFI

Impact to RDFIs

When the RDFI discovers a name mismatch, choose one of the following courses of action:

• Post the Entry based solely on account number.
• Return the Entry as R03.
• Assist the Receiver by communicating directly with the ODFI/Originator.

Effective March 20, 2015: Dishonored Returns and Contested Dishonored Returns Related to an Unintended Credit to a Receiver
There are two new return codes to assist Originators, ODFIs, and RDFIs to rectify situations in which the reversal process resulted in, or didn’t resolve unintended credit to the Receiver.

Originators and ODFIs can use the new R62 (Return of Erroneous Debit or Reversing Debit) only in the following situations:

• When a debit Erroneous Entry and a subsequent credit Reversing Entry are both transmitted to the Receiver’s account, but the erroneous debit is returned while the reversing credit is posted and made available to the Receiver.
• When a credit Erroneous Entry and a subsequent debit Reversing Entry are both transmitted to the Receiver’s account, but the reversing debit is returned while the erroneous credit is posted and made available to the Receiver.

If you are an ACH Originator, you can request that your ODFI dishonor a return in order to correct and resolve an erroneous or unintended credit to a Receiver.

In addition, ensure that R62 is only used when the associated credit entry (the Reversal or the erroneous credit) was not also returned by the RDFI.

RDFI’s can use the new Contested Dishonor R77 (Non-Acceptance of R62 Dishonored Return) if either of the following situations exist.

• the RDFI returned both the erroneous entry and the reversal entry to the ODFI
• the RDFI was unable to recover the funds from the Receiver

Example

ABC Company sends two ACH Credit transactions to Receiver A in error and subsequently sends a reversing ACH Debit to Receiver A to correct the error. Both ACH Credit transactions post to Receiver A’s account. If Receiver A returns the reversing ACH Debit to ABC Company and keeps the erroneous ACH Credit, ABC Company can dishonor the return of the reversing ACH Debit with an R62 return reason code. However if Receiver A’s Bank returned both the erroneous ACH Credit and the reversing ACH Debit to ABC Company or if Receiver A no longer has the available funds in their account, then Receiver A’s Bank can Contest the Dishonored Return with an R77 reason code.

2015 - January: Return Fee Entry Formatting Clarification 
Effective January 1, 2015, consumers that received an electronic Return Entry fee posted to their account often times could not link the return fee to an authorized transaction at a merchant. The NACHA rule change clarifies that the Individual Name field in the PPD Return Entry Fee transaction is used to link the fee to the original authorized ARC, BOC, or POP transaction that was returned unpaid. The Individual ID field could contain the Receiver’s name, reference number, identification number or code of the merchant to identify the customer. This change should have no impact on ACH participants as it recognizes current best practice regarding the formatting of fees for check conversion entries.

2014 - September: Prenote Waiting Period Change and B2B Authorization Records 
ACH Rules Updates - Effective September 19, 2014

Prenote Waiting Period Changed from 6 to 3 Banking Days
There are two upcoming ACH Rule changes pertaining to ACH origination processing.   First, if you are accustomed to using prenotes to validate the receiver's bank routing and account information and waiting six banking days before initiating 'live' entries, that time period has been reduced from six to three banking days.   Keep in mind that prenotes continue to be optional and they validate the bank routing and account information but not that the receiver's name on the prenote is connected to or associated with the account.  This new rule is located in the NACHA Rules at Article 2, Subsection 2.6.3.  Following is a copy of this rule for your convenience:

An Originator that has originated a Prenotification Entry to a Receiver's account may initiate subsequent Entries to the Receiver's account as soon as the third Banking Day following the Settlement Date of the Prenotification Entry, provided the ODFI has not received a Return or a Notification of Change related to the Prenotification.  If the ODFI receives a Return Entry or a Notification of Change in response to the Prenotification by the opening of business on the second Banking Day following the Settlement Date of the Prenotification, the Originator must not transmit subsequent Entries to the Receiver's account until it has remedied the reason for the Return Entry and made the correction requested by the Notification of Change.

Providing Record of B2B Authorizations within 10 Banking Days
The second rule pertains to you if you are originating ACH entries to non-consumer accounts which you might classify as vendors, trading partners, or business customers.  Currently, the ACH Rules state (Article 2, Subsection 2.3.1) that the Originator must obtain authorization from the Receiver and that the Originator must obtain the Receiver's agreement to be bound by the ACH Rules (Article 2, Subsection 2.3.3.1.  The ACH Rules are not specific regarding how the agreement is to be obtained or in what form.  However, the approved Rule change will obligate ACH originators that are sending ACH entries to other companies to supply evidence of authorization or supply contact information as requested by the receiving company.  Originators must provide this information within 10 banking days of a written request from the receiving financial institution.  You are encouraged to review your policies and procedures with regards to obtaining and retaining agreements and authorizations so that documentation can be quickly located in the event that PNC or your company is asked to provide this information. Furthermore, this new rule is located in the NACHA Rules at Article 2, Subsection 2.3.3.3   Following is a copy of this rule for your convenience:

 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.

2014 - March: Person-to-Person ACH Payments 
Currently when making a transfer of funds or payment to another person, consumers that utilize their financial institution via the Internet or mobile services to send money to another consumer are most likely not aware that the type of ACH debit posting to the account to pay for that transfer is labeled with the Standard Entry Class (SEC) Code of "WEB". The ACH WEB debit that posts to the account of a consumer who initiated the ACH debit, signifies that the consumer had initiated and authorized the debit entry either via the Internet or a mobile device.

Up until the time of this Rule change, the credit portion of the transaction to the receiving consumer has been labeled with the SEC Code of "PPD", commonly used for Direct Deposit or "CIE", commonly used for the credit to a biller as a result of a consumer's bill payment push. Now with the Rule change, the ACH Rules allow the use of the SEC Code "WEB" for the ACH credit going to the receiving consumer. Prior to the rule change, an ACH WEB credit entry could only be a reversal of an ACH WEB debit.

As of March 21, 2014, the NACHA Rules will allow the use credit WEB Entries for P2P transactions. It will be mandatory for all P2P Services offered by you or a third party to use credit WEB Entries for P2P transactions sent via ACH by no later than March 20, 2015. Specifically, the P2P Rule amendment:

• Defines a P2P payment in the Rules: 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;
• Allows a credit version of the WEB Standard Entry Class (SEC) Code to be used for a P2P credit transaction sent from a consumer's DDA;
• Establishes standardized formatting requirements for such a WEB credit and ensures that for WEB credits - and WEB debits if used to fund P2P transactions - the Company Entry Description in the Company/Batch Header Record contains a value that lets the Receiver know that the entry is a P2P transaction;
• Clarifies how Notifications of Change (NOCs) should be handled for P2P WEB credits and for bill payment CIEs; and
• Allows an Addenda Record for a WEB credit to include up to 80 characters of payment related information in free form text.

The impact of the P2P Rule amendments are primarily to financial institutions and third-party processors that facilitate person-to-person funds transfers utilizing the ACH network.

2013 - September: ACH Security Framework 
On September 20th, 2013, the ACH Security Framework Rule change will be implemented. The ACH Security Framework establishes minimum data security obligations for ACH Network participants to protect ACH data within their purview. This Rule is aimed at protecting the security and integrity of certain ACH data throughout its lifecycle, and is intended to be consistent with other data security obligations of ACH Network participants.

The Rule implementation includes three sets of rules:

• Protection of Sensitive Data and Access Controls
• Self-Assessment; and
• Verification of Third-Party Senders and Originators

Protection of Sensitive Data and Access Controls
The ACH Security Framework Rule requires non-consumer Originators, Participating DFIs (Depository Financial Institutions), Third Party Service Providers, and Third-Party Senders to establish, implement, and, as appropriate, update security policies, procedures, and systems related to the initiation, processing, and storage of Entries.

These policies, procedures, and systems must:

• Protect the confidentiality and integrity of Protected Information;
• Protect against anticipated threats or hazards to the security or integrity of Protected information; and
• Protect against unauthorized use of Protected Information that could result in substantial harm to a natural person

The amendment defines Protected Information as the non-public personal information, including financial information, of a natural person used to create, or contained within, an Entry and any related Addenda Record. This not only covers financial information, but also includes sensitive non-financial information (such as health information) that may be incorporated into the Entry or any related Addenda Record. This Rule applies to consumer information only, which is consistent with existing regulations and also with the approach of aligning the ACH Security Framework with existing industry regulations and guidance. However, impacted ACH participants may wish to apply the rule so that it covers all customers.

Security policies, procedures, and systems of ACH participants covered by this Rule must include controls on system access that comply with applicable regulatory guidelines. The systems impacted include all systems used by the ACH participate to initiate, process, and store Entries.

Self Assessement
Each Participating DFI, Third-Party Service Provider, and Third-Party Sender is required under the amendment to verify, as part of its annual ACH Rules Compliance Audit, that it has established, implemented, and updated the data security policies, procedures, and systems required by the ACH Security Framework Rule.

The annual Rules Compliance Audit applies directly to DFIs, Third-Party Providers and Senders, but not directly to Originators. Originators are bound to the NACHA Operating Rules through their origination agreements with their ODFIs. Therefore, the Originators must ensure that they have existing policies, procedures, and systems in place that will enable compliance with the ACH Security Framework.

Verification of Third-Party Senders and Originators
This Rule requires ODFIs to use a commercially reasonable methods to establish the identity of each non-consumer Originator or Third-Party Sender with whom the ODFI enters into an origination agreement at the time the agreement is created.

If you are an Originator, Third-Party Senders, or Third Party Service Providers, it is your responsibility to determine if existing policies, procedures, and systems are sufficient to comply with the ACH Security Framework Rule. If you do not have such policies, procedures and systems in place, you will need to establish and/or update policies, procedures, and systems to ensure compliance. Additionally, if you are Third-Party Sender or Third-Party Service Provider, you will need to add such verification to your annual Rules Compliance audit.

For additional information regarding this Rule change, or to request a copy or access to the latest ACH Rules from PNC, please contact your Treasury Management representative to request an access code to achrulesonline.org.

2013 - September: Healthcare Payment via ACH
On September 20th, changes to the NACHA Operating Rules related to Healthcare Payments via ACH go into effect. These changes are an integral part of the implementation of healthcare industry standards mandated by the Patient Protection and Affordable Care Act (ACA) that carry a January 1, 2014 compliance deadline.

Specifically, the Rule requires health plans to identify clearly the CCD entries that are Health Care EFT claim payments to providers through the use of the specific identifier "HCCLAIMPMT" as the Entry Description of the ACH transactions. For a CCD Entry that contains the healthcare indicator, the health plan must include an addenda record that contains the ASC X12 Version 5010 835 TRN (Reassociation Trace Number) data segment, and to identify itself in the transaction by its name as it would be known to the provider. The TRN data segment, along with additional information contained with the Entry, is required by healthcare providers to reassociate the Health Care EFT Transaction with the electronic remittance advice (ERA) that is transmitted separately.

The Rule also requires the RDFI to provide, either automatically, or upon request, the information contained within the Payment Related Information field of the addenda record no later than the opening of business on the second banking day following the Settlement Date of the Entry. This Rule requires the RDFI to offer to the healthcare provider an option to receive or access the Payment Related Information via a secure and electronic means.

The Rule also provides for the use of a second data segment terminator, the tilde ( ~ ), to any data segments carried in the Addenda Record of the CCD Entry.

Health plans may begin using the transaction identification and formatting standards within this Rule earlier than the effective date; use of the new standards should not cause any processing problems for Receivers. Similarly, RDFIs that do not currently offer an electronic option for the delivery or provision of payment related information may do so as soon as they are ready.

For additional information regarding this Rule change, or to request a copy or access to the latest ACH Rules from PNC, please contact your Treasury Management representative to request an access code to 'achrulesonline.org'.

2013 - September: Effective Period of Stop Payment to Non-Consumer Account
On September 20, 2013, the Rules regarding Stop Payments - Effective Period of Stop Payment to Non-Consumer Account will go into effect. This Rule revises 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.

Prior to this change, a stop payment order on a Non-Consumer Entry will expire after six months, unless it is renewed in writing. The Rules will now take into account two additional conditions under which an RDFI may remove the 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.

This Rule incorporates these additional conditions into the Rules reflecting current business practices and aligning to a greater extent corporate and consumer stop payment rules. The new Rule does not impact the existing reference to the six month effective time period for a stop payment order but recognizes that the stop payment order will lapse at the earliest of these three conditions.

2013 - March: IAT Modifications and Refinements 
Effective March 15th, 2013, several IAT Modifications and Refinements will go into effect.

RETURN REASON CODE R16 - ACCOUNT FROZEN/ENTRY RETURNED PER OFAC INSTRUCTION
On March 15, 2013, the Rules modify the title of R16 and expand the use of R16 to include IAT transactions that are returned due to instructions from OFAC.

CORRECTED DATA FOR IAT ENTRIES - NOC CODE DESCRIPTIONS

• Corrects the descriptions of the following change codes relative to IAT: C04 (Incorrect Individual Name/Receiving Company Name) and C09 (Incorrect Individual Identification Number)
• Corrects the "Notes" section for these code descriptions to reflect the proper field lengths for these data elements, as they are used within the Corrected Data Field of an IAT entry.

Note that these changes do not impact NOC record layouts or formatting.

RETURN REASON CODE R85 - INCORRECTLY CODED OUTBOUND INTERNATIONAL PAYMENT

• The RDFI/Gateway has identified the entry as an outbound international payment and is returning the entry because it bears an SEC Code that lacks information required by the Gateway for OFAC compliance.

NOC CHANGE CODE C14 - ACCOUNT FROZEN/ENTRY RETURNED PER OFAC INSTRUCTION
This is a request for future entries to be identified as IAT and convey information required by the Gateway for OFAC Compliance. Note that C14 NOCs must contain the value "IAT" within the first 3 positions of the Corrected Data Field of the NOC.

2012 - September: IAT Modifications and Refinements
On September 21st, 2012, the International ACH Transaction ("IAT") Standard Entry Class code will receive additional modifications and refinements. These changes to the NACHA Operating Rules ("Rules") clarify the minimal description standards for IAT entries, provide Gateway notifications of rejected inbound international payments, and provide a new transaction type code to identify remittances.

Minimum Description Standards for IAT Entries
This change clarifies the minimum description standards within the Rules as they relate to IAT entries. As with any entry to a consumer account, the RDFI of an inbound IAT entry must provide the consumer with certain descriptive information in accordance with the requirements of the Rules and Regulation E. With the implementation of IAT, however, the minimum description standards within the Rules were not modified to make explicit that IAT entries also convey information related to terminal city, terminal state, terminal identification code/location, and check serial number for certain types of payments, and that, when such information is present in an IAT entry, it must be included on the consumer's bank statement.

If you originate IAT entries today that contain information such as terminal city, terminal state, your Receivers may see greater clarity of information after the new Rules implementation on September 21st, 2012, if their current RDFI did not previously provide these descriptions on their statements.

Gateway Notification of Rejected Inbound International Payment
This Rule change establishes a requirement for the Gateway Operator to notify the intended RDFI if an inbound international payment transaction was rejected or blocked because it would violate U.S. law and provide minimum information related to the transaction, unless prohibited by law.

Transaction Type Code to Identify Remittances
This Rule change expands the list of eligible code values that may be included within the transaction type code field. On September 21st, 2012, the code "REM" may be used to identify international payments through a remittance product or service.

For additional information regarding this Rule change, or to request a copy or access to the latest ACH Rules from PNC, please contact your Treasury Management representative to request an access code to 'achrulesonline.org'.

2012 - March: Expansion of ARC Application and IAT Modifications and Refinements
On March 16, 2012, two new NACHA Operating Rules ("Rules") went into effect. The first Rule change affects the ARC (Account Receivables Entry) for the conversion of checks to ACH, and the second rule change affects IAT (International ACH Transactions) transactions.

Expansion of ARC Application
For the ARC application, previously, eligible checks were allowed for the ARC application only if they were received through the U.S. mail or at a dropbox location. The Rule change expands the use of ARC application for the conversion of checks, now allowing the use of ARC for the conversion of checks tendered in person for the payment of a bill at a manned location.

If you are currently or considering converting checks using the ARC application through the ACH Network, you may choose to expand the use of the ARC application to include checks received in person at a manned location.

IAT Modifications and Refinements
The IAT Modifications and Refinement Rule change contains additional clarifications and refinements to allow more efficient and accurate processing of international payments in the ACH network.

IAT Entries and the Effective of Illegality
The Rule change expands the subsection to clarify that the Participating Depository Financial Institution ("DFI") must comply with all requirements of the Rules for any non-suspect transaction. An RDFI may not delay posting solely because an entry is an IAT. If, after initial review, an RDFI believes an IAT is a suspect transaction that requires additional examination, posting may be delayed to perform that examination.

Clarifications of Rules Exceptions for IAT Entries
This Rule change clarifies the conditions and circumstances under which specific provisions of the Rules do not apply to certain IAT Entries. In some cases, these exclusions relate to domestic ACH Network operational processes that may not have counterparts in the payment systems of the foreign countries. Specifically, the change:

• defines specific authorization requirements for Outbound IAT Entries.
• updates the current list of Rules not applicable to Outbound IAT Entries and clarifies that certain ACH functions apply only to the extent that they are permitted by the laws and payment system rules of the receiving country.
• establishes a new subsection to identify specific Rules that do not apply to Inbound IAT Entries.
• broadens the Rules to (1) incorporate an explicit statement that a Participating DFI acting as a Gateway assumes the responsibilities and warranties of an RDFI for each Outbound IAT Entry it transmits, with the specific exception of the rights and obligations between the DFI and the foreign receiver, and (2) update the current list of Rules not applicable to Outbound IAT Entries.
• requires Gateways to notify their foreign contacts of any changes requested through the NOC (Notifications of Change) process to ensure proper processing of future ACH Entries.

Required Gateway Agreements and Authorizations for Outbound IAT Entries
This Rule change revises the current Rule that requires a Gateway to enter into an agreement with and obtain specific authorization from the Originating Depository Financial institution ("ODFI") prior to transmitting Outbound Entries. This is in recognition of the international payments models involving the Gateway and a party other than the ODFI, such as Gateway?s own account-holder or customer. Specifically, the Rule:

• broadens the Gateway agreement requirements to permit parties other than the ODFI to have an agreement with the Gateway for the transmission of Outbound IAT Entries.
• broadens the Gateway authorization requirements to permit parties other than the ODFI to authorize the Gateway to transmit Outbound IAT Entries to and settle with a Foreign Gateway for further credit to the foreign receiver?s account.
• revises the description and cross-reference sections of Return Reason Code R81 to broaden the discussion regarding the lack of necessary agreements.

Return of Outbound IAT Entry by Foreign Gateway - Transmission of ACH by Gateway to ODFI
This Rule change clarifies the timeframe for a Gateway to transmit an ACH Return Entry for any outbound IAT Entry that was properly returned to it by a Foreign Gateway. Under the current Rules, RDFIs have a defined time period under which they must transmit Returns for domestic Entries. However, no similar provision exists today for the processing and return of entries received by a Gateway from outside the U.S. This change adds a specific obligation and time frame for a Gateway to transmit a return entry related to an Outbound IAT Entry that was properly returned to it by the Foreign Gateway.

Identification of the Foreign Funding Financial Institution Within an ACH Entry
This Rule change revises the descriptions of the four fields within the Fourth IAT Addenda Record to clarify that this information, when contained in an Inbound IAT entry, must identify the foreign financial institution that provides the funding for the transaction. The four fields that are impacted by this change are: the Originating DFI Branch Country Code, Originating DFI Identification, Originating DFI Identification Number Qualifier, and Originating DFI Name.

Clarification of Originator Identification Field
This Rule change revises the definition of the Originator Identification Field within an IAT entry to permit the inclusion of additional identifying information for use by the ODFI. This change explicitly allows Originators and ODFIs to include a one-digit alphameric code within the first position of the field to allow for further identification and processing of the payment by the ODFI.

If the Originator is not established under the laws of a state or the United States or is not a natural person, the DDA account number at the foreign financial institution may be included. If the DDA number exceeds 9 characters, the last 9 characters would be used. If there are 9 or fewer characters in the account number, the entire number would be used.

If a Third Party Sender was used for the entry, the tax identification number of either the Originator the Third-Party Sender may be used when the ODFI has a contractual relationship with the Third-Party Sender rather than the Originator of the entry. The Originator Name field must be populated with the Originator's name and not of the Third Party Sender.

Return Reason Codes R80-R84 ? Clarification of Use For Outbound IAT Entries Only
This Rule change clarifies that these codes are for use by Gateways only. This Rule clarification should have no impact to the ACH participants.

Expansion of Return Reason Code R84 (Entry Not Processed By Gateway Operator)
This Rule change expands the use of this return code to allow a Gateway to return an IAT Entry when the foreign payment system does not support the function(s) needed to process the transaction.

If you are a current IAT originator or are looking to originate IAT transactions, and would like additional information or clarifications regarding these Rule changes, please contact your Treasury Management representative to request an access code to 'achrulesonline.org'.

2012 - January: Corporate Account Takeover - Availability Exception Option
On January 1, 2012, a new amendment to the NACHA Operating Rules ("Rules") regarding Corporate Account Takeover went into effect. This amendment provides an option for a Receiving Depository Financial Institution (RDFI) to exempt itself from the funds availability requirement for an ACH credit when it reasonably suspects that the ACH credit is not authorized. The Rule is intended to allow an RDFI the option to use additional time to investigate a suspicious credit prior to making funds available to a Receiver. The additional time might enable Originating Depository Financial Institutions (ODFIs) and RDFIs to identify instances of unauthorized credit entries, and recover funds on behalf of Originators before funds are withdrawn.

Specifically, the Availability Exception Option:

• Provides an RDFI that reasonably suspects that a credit entry is unauthorized with an exemption to the Rules provisions requiring the RDFI to make certain credit entries available to customers more quickly than required to under Regulation CC; and
• Requires the RDFI promptly to notify the ODFI if the RDFI makes use of this exemption to the funds availability requirements of the Rules.

This exemption does not allow the RDFI to delay availability because of the RDFI?s own errors in processing an entry.

PNC is currently evaluating its processes for determining the feasibility of implementing the Availability Exception Option as an RDFI.

For more information about this specific Rule change, please visit http://www.nacha.org/. For the latest copy of the ACH Rules, please contact your Treasury Management representative to request an access code to 'achrulesonline.org'.

2011 - September: Enhancements to ACH Applications and New Rule Requirements
On Nov. 19, 2010, the NACHA Voting Membership, of which PNC is a part, approved several enhancements to existing ACH applications.  These enhancements were made to encourage greater use of these ACH applications by removing the barriers to use as well as conforming to the recent industry developments and regulatory changes.  These enhancements include:

1. Expansion of the scope of the TEL application to permit recurring consumer transactions.
2. Elimination of the requirement that Originators have opt-out procedures for ARC and BOC transactions.
3. Establishment of authorization and identification requirements for ACH debits used to collect return fees for certain checks and ACH debits due to insufficient funds (NSF).
4. Expansion of the scope of XCK application to permit its use for certain damaged checks.

The effective date regarding the provision for ARC and BOC opt-out procedures is March 18, 2011, while the other provisions will be effective on September 16, 2011.

1. The TEL application was formerly restricted to single Entries to conform with the interpretation of Regulation E when it was introduced.  Therefore, billers were not able to establish recurring billing via telephone and instead had to direct consumers to its website or other means to set up recurring authorization.  This rule will expand the TEL application to allow recurring debits given sufficient oral authorization that complies with Regulation E.

If you are: using the TEL application to receive funds from your customers and/or are looking to set up recurring payment with new customers over the telephone,

Consider: setting up recurring payment option with the expanded TEL application.

1. ARC and BOC had an opt-out provision that required the Originators of ARC and BOC Entries to have procedures in place to allow the Receivers to opt-out of the check conversion process.  The rule change will remove this requirement while still allowing the Originators to continue to have an opt-out procedure should they choose to do so.

 If you are:  currently or considering converting checks by originating ARC or BOC ACH entries,

Consider:  whether or not an opt-out procedure is appropriate for your customers.

1. Merchants and billers will be able to use a new Entry type - a Return Fee Entry - that can be used for the purpose of collecting return fees for certain ACH debits or other qualifying checks that are returned unpaid. 

If you are:  generating ACH debits and depositing checks from your customers and looking for an efficient, inexpensive and effective way to collect return fees,

Consider: with proper authorization, using the ACH network as your primary method to collect the return fee.

1. The ACH Network can now clear certain checks that cannot be imaged or processed but contain enough formation to clear as an ACH Entry (XCK), with certain limitations.
   Note:  Only financial institutions can originate XCK entries, but it is possible that a check that you write may be cleared as an ACH debit transaction under this rule.

The ACH Rule changes described above do not fully encompass all of the requirements when deploying the Standard Entry Class (SEC) codes in your electronic payment program.    For a more complete description of related ACH Rules requirements when utilizing TEL, ARC, BOC, and/or XCK, please contact your PNC representative.

2010 - March: Consumer Debit Authorizations and Stop Payments
On Friday, March 19, 2010, two new ACH Rule amendments went into effect. The changes pertain to consumer accountholders who receive ACH debits. The Authorization and Returns change affects procedures for returning unauthorized debits and the Stop Payment change revises the requirements for placing stop payments on consumer accounts.

Authorizations and Returns The Authorization and Returns Rule changes are aimed at enhancing the quality of transactions in the ACH Network by more clearly defining an Originator's obligations for obtaining a consumer's authorization, and by improving processes related to the return of debits that Receivers claim are unauthorized. Highlights of the NACHA Rule changes include the following:

• Authorization Requirements - The authorization used by the Originator (the company sending an ACH debit) must be readily identifiable as an authorization and its terms must be "clear and readily understandable." Any purported authorization that is not clear nor readily understandable, is not a valid authorization and the transaction may be returned as unauthorized.
• Definition of an Unauthorized Entry - Part of the definition of an unauthorized entry has been changed from being a transaction that was initiated in an amount "greater than" the amount authorized by the Receiver (the accountholder receiving ACH debit entries) to being a transaction that was initiated in an amount "different than" the amount authorized by the Receiver.
• Modifications to the Written Statements - The document used by RDFIs (Receiving Depository Financial Institutions) to collect information regarding unauthorized consumer ACH debits is now entitled, "Written Statement of Unauthorized Debit" in lieu of the prior title, "Written Statement Under Penalty of Perjury" or "Affidavit" in order to avoid triggering any state notary requirements.

Stop Payments and Regulation E The ACH Rule change revises the requirements for the application of stop payment orders related to ACH entries destined to consumer accounts and realigns the NACHA Rules with the requirements of the Federal Reserve Board's Regulation E. Specifically, the Rule will:

• Eliminate the six-month time period after which a stop payment order placed by the consumer lapses.
• Provide that, where the stop payment order applies to more than one debit entry, the order remains in effect until all such entries have been stopped.
• Permit RDFIs to require, in cases where the Receiver desires to block all future payments related to a specific authorization/Originator, that the Receiver confirm in writing that the Receiver revoked authorization with the Originator.

ACH entries that are returned due to a stop payment order are returned by the RDFI with the return reason code R08 (Payment Stopped). Return reason codes and their definitions can be found in Appendix Five of the 2010 ACH Rules.

If you would like to receive a copy of the ACH Rules on CD ROM, contact your PNC account representative.