ACH Articles, Tools & Resources - Iowa Bankers Association

Articles

FAQs

Origination

Returns

Stop Payment

Written Statement of Unauthorized Debit

Reversal

Tax Refund ACH Processing

Same Day ACH

ACH Direct Access

ACH Program

Origination

Question: One of our Originators received a Notification of Change (NOC) for an entry with a wrong account number. What are the rules regarding responding to and/or making a correction? What are we, as the Originating Depository Financial Institution (ODFI), responsible for?

Answer: It is the Originator’s responsibility to 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. It is the ODFI’s responsibility to provide the NOC information to the Originator and have procedures in place to ensure that the Originator has made the requested change within the required timeframe or prior to sending another entry to the Receiver’s account. If the change is not made, it may result in a Nacha rules violation.

Question: We have an ACH originator that has inquired about beginning to initiate WEB debit entries. We currently do not have any other ACH Originators originating WEB entries. It appears one of the requirements for originators who initiate WEB entries is an audit. What type of audit is required for the Originator and what are the requirements for the ODFI relative to the Originator’s audit requirement?

Answer: The originator will need to conduct, or have conducted on its behalf, an annual data security audit. The originator must conduct this audit using a qualified independent person who understands IT security. Refer to the annual data security audit details within Section V, Chapter 48 in the NACHA rules book.

The goal of the audit is to confirm the receivers’ financial information is protected by security practices and procedures that ensure the financial information the originator obtains from receivers is protected by commercially reasonable security practices that include adequate levels of:

Physical security to protect against theft, tampering, or damage,
Administrative, technical, and physical access controls to protect against unauthorized access and use, and
Network security to ensure secure capture transmission, storage, distribution and destruction of financial information.

See the NACHA rules book for additional details on the minimum components of the audit.

Since the ODFI is responsible for its originators and the type of transactions initiated, the ODFI should at a minimum, annually request attestation/confirmation from the originator that the data security audit has been conducted.

Question: We understand there have been enhancements to the ACH rules as part of the Meaningful Modernization amendments to provide greater clarity on the topic of authorizations for debit entries to consumer accounts. Can you explain the minimum information required to be included in such authorizations?

Answer. Correct, these amendments to the ACH rules will replace various sections of the 2021 NACHA Operating Guidelines effective Sept. 17, 2021. For additional detailed descriptions of the changes, see the Revisions section of the 2021 NACHA Operating Rules. The requirements described below will affect any new debit authorizations completed; however, the bank is not required to get revised authorizations from existing consumers.

An originator of a debit entry (whether the bank originating an ACH debit for its customer or the bank’s originators) must obtain a written authorization as expressly permitted by the ACH Rules. The originator must ensure that each consumer debit authorization includes, at a minimum, all of the following elements:

Language clearly stating if the authorization is for a single entry, multiple entries or recurring entries;
The amount of the entry or entries, or a reference to the method of determining the amount of the entry(ies);
The timing of the entries, to include the start date, number of entries and frequency of entries;
The Receiver’s name or identity;
The account to be debited and whether the account is a demand deposit account or a savings account;
The date of the authorization; and
Language to instruct the Receiver how to revoke the authorization directly with the Originator. This must be clear to identify the time (how many days prior, etc.) and manner (phone, email, address, etc.) in which the Receiver must communicate the revocation to the Originator.

Question: I am confused about the difference between recurring and subsequent entries. Could you explain the difference?

Answer: To understand the difference, we must first define a single entry, recurring entry, a subsequent entry, and a standing authorization:

Single Entry:A credit or debit initiated by an originator in accordance with the receiver’s authorization for a one-time transfer of funds to or from the receiver’s account.
Example: I authorize my insurance company to deduct my auto insurance premium from my checking account one time.

Recurring Entry:An entry to a consumer account that recurs at substantially regular intervals without further affirmative action by the receiver to authorize future entries.
Example: I authorize my insurance company to deduct my auto insurance premium from my checking account every month via ACH. The payments are made without any further action by me (the receiver).

Subsequent Entry:An entry to a consumer account that is initiated by a receiver’s affirmative action in accordance with the terms of a standing authorization. A standing authorization is an advance authorization by a receiver of future entries to the receiver’s account that requires further affirmative action by the receiver to initiate those future entries. Subsequent entries will allow originators and receivers greater flexibility in how payments are made.
Example: I want to decide when and how to make my auto insurance premium payments each month. I authorize ABC Insurance to debit my account providing my account information within a standing authorization and will let the company know when they can take a payment and what payment method to use each month (ACH debit to my checking account, charge to my credit card, etc.) via a text message, automated phone system or via the company’s app.

Keep in mind, subsequent entries can be initiated as a WEB (internet initiated/mobile entries), TEL (telephone initiated entries) or PPD (prearranged payment and deposit entries) depending on how the initial authorization was obtained and how the subsequent entry was initiated.

Question: We have a business customer who wants to provide authorizations for the bank to create an ACH file for their rental payments. In this scenario, is the bank or the business customer the Originator? Are we required to obtain an ACH Origination Agreement since we are processing the file?

Answer: The business customer would be considered the Originator since they are obtaining the authorization to create an ACH entry. The bank is considered the ODFI (Originating Depository Financial Institution). An ACH Agreement is required when the ODFI has a business customer who obtains authorizations from their clients and provides the authorizations to the ODFI to create an ACH file to send on behalf of the business customer. In essence the ODFI is doing part of their “bookkeeping” by creating the ACH file for them.

Question: As an ODFI, can I dispute an unauthorized entry fee?

Answer: No. The assessment of the fee is based on the return entry code. There is nothing within the Rules that authorizes ODFIs to challenge fee assessments.

Question: As an ODFI, can I pass on the amount of the unauthorized entry fee to the applicable Originator who initiated the entry?

Answer: Yes. However, you may want to check your Agreement to ensure it allows you to pass on fee assessments. While the Rules do not require ODFIs to update agreements to include passing this fee on to the Originator, it is a best practice to disclose any fee associated with ACH origination and returns.

Returns

Question: Our customer has a recurring EFT set up through our bank to debit their account at another bank to make a payment on the loan at our bank. The loan was paid in full yesterday. Today, the EFT payment is in our nonpost as our system attempted to process and post the transaction to a closed account (the paid off loan). Do I return this entry R02 (Account Closed), or can I post this to another deposit account they have with our bank?

Answer: The transaction should not be posted to any account other than where the EFT authorization has indicated. In this case, since the loan has been paid off and is now considered “closed,” the entry should be returned as R02 (Account Closed).

Question: Our bank received a returned ACH entry with a return reason code R29 Corporate Customer Advises Unauthorized, however our Originator has a valid authorization for this entry from the Receiver. How can we return this entry back to the Receiver? There doesn’t seem to be a return reason code to dishonor this type of return.

Answer: There is no valid reason to dishonor the entry; therefore, the Originator and the Receiver must negotiate a resolution outside of the ACH payments system and rules. The Nacha rules presume they are business partners and have terms in their agreement that are legally binding. The Originator typically would directly contact the Receiver and remind them of those terms, and they would agree on the next steps for payment.

Question: We have a business customer who does not recognize a transaction on their account and has reported it unauthorized. More than two banking days have passed to return the entry R29 (corporate customer advises not authorized) and the Standard Entry Class Code originated for this transaction is a WEB (consumer SEC code). How do we process this return? What return reason code will we use? Are we required to obtain a Written Statement of Unauthorized Debit (WSUD)?

Answer: Because the SEC code used to generate the entry was a WEB (a consumer SEC code) but posted to a non-consumer (business) account, you will process the return using a consumer return reason code of R10 (customer advises originator is not known to receiver and/or originator is not authorized by receiver to debit receiver’s account). The return time frame will be the same as for a consumer customer account – 60 calendar days from settlement date. A completed and signed WSUD must be obtained prior to the return of the entry.

Question: We have a consumer customer who does not recognize a transaction on their account and has reported it unauthorized. The Standard Entry Class Code originated with the entry is a CCD (corporate credit or debit). How should we process this return where a non-consumer SEC code posted to a consumer account? What return reason will we use? Are we required to obtain a Written Statement of Unauthorized Debit (WSUD)?

Answer: When a corporate SEC code (CCD or CTX) is used for entries to consumer accounts the proper return reason code to use is R05 (unauthorized debit to consumer account using a corporate SEC code). Because this is a consumer account, a completed and signed WSUD is required prior to the return of the entry. This type of return must be processed within 60 calendar days of settlement of the original entry.

Question: When is it appropriate to use ACH return code R11? Is any additional information required when this code is used?

Answer: Return Reason Code R11 will alert the ACH Originator there was an error in a debit, rather than just stating the debit was an unauthorized payment. Examples of instances of when Return Reason Code R11 could be used include:

The debit was made for an incorrect amount.
The debit was made earlier than authorized.
The debit is part of an incomplete transaction.
The debit was improperly reinitiated.

For ARC, BOC, or POP entries reasons include the source document was ineligible; the notice was not provided to the customer; or the amount of the debit was not accurately obtained from the source document.

Additional information is required when using this return code. Debit returns using Return Reason Code R11 should include the reason for return so the Originator has the ability to address the error. Requirements for returning and correcting the entry are as follows:

The Receiving Depository Financial Institution (RDFI) will be required to obtain the Receiver’s Written Statement of Unauthorized Debit (WSUD) to return the entry.
The return entry must include a specific reason for the return in the Addenda Information Field of the Addenda Record.
The RDFI return timeframe is 60 days from the Settlement Date.
The Originator must transmit the correction Entry within 60 days of the Settlement Date of the R11 Return Entry, if applicable.
The Originator is not required to obtain a new authorization when correcting the entry. (October 2020)

Let’s consider an example to illustrate: A landlord of rental properties, both business and residential, obtains written authorization from the tenants for the monthly rent. The landlord provides the authorizations to their bank (ODFI) who then creates an ACH file on behalf of the landlord and then processes the file for the landlord. In this example, the landlord needs to enter into an ACH Agreement with the ODFI. While not mandatory, it’s recommended ACH origination services be covered in the ACH agreement when applicable. Also, the Originator’s (landlord) readily recognizable name must be in the Company Name field of the Company Batch Header Record (not the ODFI). (October 2020)

Question: Our ACH processing department believes an entry containing invalid account information was initiated under questionable circumstances. The entry was for $0.01 and may be a fraudulent attempt to validate an account number, how should the bank proceed to return this type of entry?

Answer: The entry may be returned using Return Reason Code R17. R17 can be used to return entries containing invalid account information and/or the Receiving Depository Financial Institution (RDFI) believes the entry has been initiated under questionable circumstances. For example, the name of the receiver is different than the account owner for a debit entry that is for a few cents. This may be an attempt to validate credentials of an account in order to make purchases or transfer funds using the ACH system. Another example on when R17 can be used is when a credit entry is presented that is much larger than normal or out of character for receiver. The receiver may be unintentionally involved in a money mule scheme.

The use of R17 is optional and at the discretion of the RDFI. If the RDFI elects to use Return Reason Code R17 to return a debit or credit entry, the description “QUESTIONABLE” must be in the addenda information field. Any remaining space in the addenda information field may be used for additional information related to the return. The RDFI must return the entry within the required two banking day return timeframe. (September 2020)

Question: What should we do when we receive an ACH credit entry where the account number is valid but the name does not match the account titling or ownership?

Answer: ACH Rules allow for a debit or credit entry to post automatically, by relying on the routing number and account number in the entry (Subsection 3.1.2.) However, if the Receiving Depository Financial Institution (RDFI), becomes aware there is a mismatch (i.e. the name in the ACH entry is not on the account), other actions may be warranted. The Originating Depository Financial Institution (ODFI) warrants that all entries originated on its own behalf or behalf of its originators, are properly authorized and comply with Nacha Rules (Subsection 2.4.1).

For example, if a Social Security benefits payment entry includes an account number structure that is valid but the name on the entry doesn’t match the account name and the RDFI has knowledge of the mismatch, the RDFI should return the entry. The entry may be returned using Return Reason Code R03 (No Account/Unable to Locate Account). The RDFI must return the entry within the required two day return timeframe. (September 2020)

Question: Our Bank received several ACH debit entries for $1, all of which included invalid account numbers. The entries seem suspicious. Would it be appropriate to use the new ACH return reason code R17 (File Record Edit Criteria/Entry with Invalid Account Number Initiated under Questionable Circumstances)?

Answer: Yes. The return reason code R17 was developed to improve risk management within the ACH Network by allowing a Receiving Depository Financial Institution (RDFI) to indicate within a return the original transaction was questionable or abnormal activity. An RDFI may use return reason code R17 to return an entry containing an invalid account number which is believed to have been initiated under questionable circumstances, or may also use the R17 return code to indicate the RDFI believes the entry was initiated under questionable circumstances. RDFIs electing to use R17 for this purpose will use the description “QUESTIONABLE” in the Addenda Information field of the return. An R17 return code in conjunction with the “QUESTIONABLE” description enables these returns to be differentiated from returns for routine account number errors.

The return timeframe for use of the R17 return reason code is two banking days; that is, the return entry must be made available to the Originating Deposit Financial Institution (ODFI) no later than the opening of business on the second banking day following the settlement date of the original entry. (Sept. 2019)

Question: We recently had a consumer customer who identified two unauthorized ACH transactions posted to her account from PayPal. The customer completed the Written Statement of Unauthorized Debit (WSUD) and we returned the two entries as R10 (Customer Advises Unauthorized). The following day, the date on which we returned the two items as unauthorized, this same customer identified two credit entries posting to her account for the same amounts as the debits also from PayPal. How does the bank process the return of these credit entries and is there any specific form the customer should complete to authorize us to return the credit entries?

Answer: When a consumer or non-consumer customer contacts the bank regarding a credit entry posting to their account which they are not familiar with and would like to return, the Bank should process the return using return reason code R23 (Credit Entry Refused by Receiver). The RDFI (Receiving Depository Financial Institution) must transmit the return entry making the return entry available to the ODFI (Originating Depository Financial Institution) no later than the opening of business on the second banking day following the RDFI’s receipt of the notification of refusal of the credit entry from the bank’s customer.

Second, when a bank is directed to return a credit entry refused by the receiver, there is no written form required to be completed per NACHA rules. However, best practice would be for the bank to obtain a written statement from the consumer requesting the credit entry be returned as proof the customer did make this request. Having this written statement signed and dated will further help to evidence the credit entry was returned timely as required by the NACHA rules. (August 2019)

Question: Our customer contacted the bank with a request to return an ACH item which appears to them to be a duplicate item on their periodic statement. How can we determine if this item is truly a duplicate item for ACH return purposes to ensure we return the item using the correct return reason code?

Answer: A duplicate entry (R24) is described as an entry where the trace number, date, dollar amount and/or other data matches another transaction. The first thing to check would be the trace numbers between the two items that have posted to the customer’s account. If each item has its own trace number, it would not be considered a duplicate entry and should not be returned using code R24. If the trace number is different, the transaction is most likely an unauthorized transaction, not a duplicate. If this is the case, the customer would need to complete and sign a Written Statement of Unauthorized Debit (WSUD) and the bank can return the entry as R10 (customer advises unauthorized). (August 2019)

Question: When the bank has knowledge that a customer is deceased, we return federal benefit payments using Return Reason Codes R14 (Representative Payee Deceased or Unable to Continue in that Capacity) or R15 (Beneficiary or Account Holder [Other Than a Representative Payee]). Should we use these same Return Reason Codes for ACH returns of all items sent to a deceased person’s accounts?

Answer: Yes. The NACHA Rules, Operating Guidelines (Page OG86), explain items returned using the Return Reason Codes R14 or R15 indicate either the Representative Payee or Beneficiary of the benefit payments has died. This section further states R15 will also indicate “in the case where the payment is not a benefit payment (i.e., insurance premium debit), the owner of the account has died and the payment is being returned by the RDFI.”

Information Source – NACHA Rules – Chapter 18 – Returns for Death of Beneficiary, Representative Payee, or Account Holder

Entries may be returned by the RDFI if the RDFI has become aware of the death of the beneficiary, representative payee, or account holder. Originators should be aware of the specific differences between Return Reason Codes R14 and R15 to ensure that returns bearing these codes are handled appropriately by the Originator.

Originators should be aware that returns bearing Return Reason Code R14 – Representative Payee Deceased or Unable to Continue in that Capacity are transmitted when the representative payee assigned to receive benefit payments on behalf of the entitled individual has died. A representative payee is a person or institution authorized to accept entries on behalf of one or more other persons, such as legally incapacitated adults or minor children. Returns bearing Return Reason Code R14 indicate that the representative payee, and not the beneficiary of the payments, has died. The beneficiary is not deceased and is still entitled to the benefit payments. This Return Reason Code should not be used unless a representative payee exists.

Returns bearing Return Reason Code R15 – Beneficiary or Account Holder [Other Than a Representative Payee] Deceased will indicate either (1) in the case of benefit payments where no representative payee has been assigned, the actual beneficiary is deceased, or (2) in the case where the payment is not a benefit payment (i.e., insurance premium debit), the owner of the account has died and the payment is being returned by the RDFI.

Question: We have a BOC transaction for which the account number is wrong. The Rules manual states the R03 return code may not be used to return ARC, BOC or POP entries because they do not contain the receiver’s name in the individual name field. What return code would we use if R03 is not an option?

Answer: If the entry can’t post because the account number is wrong, but the account number structure is valid (contains the correct number of digits), then R03 would be the appropriate return code. The rule means if the account number is valid, you may not return the item simply because there is no name in the individual name field on the ACH entry.

Question: A bank customer passed away on Monday, June 7th; on Wednesday of that same week, the customer received her recurring federal benefits deposit. The bank didn’t learn about the customer’s death until the following week. Are we required to return the Social Security benefit payment to the Social Security Administration?

Answer: The answer to whether a bank is REQUIRED to return a Social Security benefit payment depends on when the payment was received, the date of death and when the bank learned of the death. According to the Social Security Administration, the financial institution must return any Social Security benefit payment paid for the month of death or any later months. If the federal benefit received in June was the benefit payment for May, the month prior to death, the bank is not required to return the payment. However, the bank must return the payment if it was received AFTER the bank was notified of the owner’s death – even if the payment was for the previous month. If the payment was received by the bank again in July, the payment would be for the month of June (the month of death), and should be returned. Social Security benefits received as a direct deposit through the ACH system must be returned using R15 (Beneficiary or Account Holder deceased).

Question: We have received a CCD (Corporate Credit or Debit) ACH transaction on a business account. The customer has stated the authorization has been revoked for the transaction. However, when we look at the return codes, R07 – Authorization Revoked by Customer is applicable only PPD, TEL and WEB transactions. What return reason code should we use?

Answer: In May 2016, NACHA provided the IBA with the following guidance on which reason code should be used in this situation. Return reason code R29 Corporate Customer Advises not Authorized is used for a CCD transaction either totally unauthorized or authorization revoked (so now it is “unauthorized”). So for non-consumer (CCD) entries use R29 – Corporate Customer Advises not Authorized for either reason.

Question: Our bank’s internal procedure for accounts that are overdrawn for an extended time period due to insufficient funds and could be in the process of being closed is to put a “freeze” on the account and only allow credits to post. In doing this, when an ACH debit attempts to post to a “frozen” account, the item will non-post. What return code reason should we use to return this non-post item? Should we use R16 (Account Frozen) or R01 (Insufficient Funds) since the account currently has a negative balance as well?

Answer: Regardless of the bank’s internal procedure for “freezing” an account that could be in the process of being closed, the return reason used should be that which will best inform the Originator as to why the item is being returned. In this case, the reason the “freeze” was placed on the account was due to insufficient funds. Therefore these items should be returned as R01 (Insufficient funds) and not R16 (Account Frozen).

Question: Can you please explain how to return an ACH credit that the Receiver does not want?

Answer: The return of an ACH credit entry is permitted if one of the following conditions is met:

A minimum amount that has been required by the Receiver has not been remitted;
The amount remitted is not the exact amount required;
The Receiver will not accept the transaction due to the account being subject to litigation;
If the transaction is accepted an overpayment will result;
The Receiver does not know the Originator; or
The credit entry has not been authorized by the Receiver.

The RDFI is required to transmit the entry to the ACH Operator by midnight of the banking day following the banking day the RDFI receives notice from the Receiver. The entry should be transmitted with the Return Reason Code R23. While the ACH Rules do not require it the RDFI should obtain a written statement from the Receiver documenting the request and the reason for the return.

Question: I have two debit entries (both PPD) that posted to a commercial checking account. The bank returned them R10 outside of the 24-hour return deadline. Shouldn’t they have been returned R29 and subject to the 24-hour return deadline since the entries posted to a commercial account? Does the SEC code or the account type drive the return code?

Answer: Commercial account holders can return any unauthorized entry as R29 in such time to make the entry available to the ODFI by the opening of business on the second banking day following the settlement date of the original entry. The Standard Entry Class Code does not matter in this case. If the unauthorized entry carries a Standard Entry Class Code that allows the 60-day return time frame, the commercial account holder can take advantage of the R10 Return Reason Code, as long as it signs the Written Statement of Unauthorized Debit. In general, the Standard Entry Class Code determines the return time frame and Return Reason Code. The exception occurs when a CCD is posted to a consumer account. The consumer can use R05 return code and is eligible for return for 60 days.

Question: Our bank has a system in place to detect excess contributions made into Health Savings Accounts (HSA). If an ACH deposit is made into an HSA account which exceeds the annual contribution limit, should the ACH item be returned R23 (Credit Entry Refused by Receiver) or R16 (Account Frozen/Entry Returned per OFAC Instruction) since the access to the account is restricted?

Answer: Should the bank want to assist the consumer in returning the excess contribution, the manner in which this is done varies depending upon the circumstances. If the Bank’s HSA account agreement contains language on what process will be followed when there is an excess contribution and the HSA owner agrees to the return of the entry, then R23 (Credit Entry Refused by Receiver) could be used. Use of the R23 return codes depends upon when the Receiver refuses the credit. So depending on the wording in the HSA agreement, if the agreement explicitly states an overpayment will be returned and by entering in to the contract, the customer is acknowledging refusal of such entry, R23 could be used. If bank management would make the decision to use the R23 return code, then consulting with the bank legal counsel for compliance with the HSA regulations is suggested.

The return code of R16 (Account Frozen/Entry Returned per OFAC Instruction) could be a better return code since HSAs have contribution limits. One of the descriptions for use of R16 is “access to the account is restricted due to specific action by the RDFI or by legal action”. An excess contribution may require the RDFI to take action and restrict deposits. Remember using the R16 return code requires returning the item within two banking days.

Finally, it is important to understand the IRS rules place the responsibility of ensuring contributions into the HSA do not exceed the contribution limits with the account holder, not the bank. The system the bank has in place certainly assists customers in this process, but this monitoring is not required. The bank’s responsibility lies in reporting the HSA contribution and distribution amounts to the IRS. (July 2019)

Stop Payment

Question: We have a customer who has identified an ACH entry in memo post on their account they did authorize but they now want to stop pay the item. Can we place a stop payment on an item that is in memo post but has not yet hard posted to the customer’s account?

Answer: Iowa code and the ACH rules give account owners the right to stop pay items drawn on their account provided the account owner provides notice to the bank in a time and in a manner that affords the bank a reasonable opportunity to act on the request. As a result, banks should have stop payment procedures in place that reflect their deposit account terms and address when such requests must be received by the bank in order to act in a timely manner on the request.

In response to your original question, yes, an account owner can request to stop pay an entry prior to the entry hard posting to the customer’s account. It is then up to your bank to determine if you have the ability to act on this request per your policies and procedures. If the customer authorized the payment but perhaps changed their mind or determined they do not have the funds available to pay the authorization and want to stop pay the entry, a stop payment request must be obtained. If the bank, according to its policies and procedures, is able to act on the request, the item can be returned using return reason code R08 (Payment Stopped). If, however, the entry which was authorized by the customer has hard posted to the customer’s account, it cannot be returned as a stop payment.

Question: Does a consumer’s stop payment order on “all future ACH debits” by a specific originator require a stop payment be placed on an account indefinitely? Is there any way to place an expiration date on these debits so that we can control the volume of stop payment orders that we monitor? We’re also very interested in best practices related to ACH stop pay requests.

Answer: Unfortunately, the NACHA Rules (Subsection 3.7.1.4) require that consumer stop payments placed on “all future ACH debits” or recurring items from a specific Originator remain in place indefinitely.

Subsection 3.7.1.4 Effective Period of Stop Payment Orders
A stop payment order will remain in effect until the earlier of:
(a) the withdrawal of the stop payment order by the Receiver; or
(b) the return of the debit Entry, or, where a stop payment order applies to more than one debit Entry relating to a specific authorization involving a specific Originator, the return of all such debit entries.

Subsection 3.7.1.3 RDFI May Require Written Confirmation of Stop Payment Orders
An RDFI may require written confirmation of a verbal stop payment order under this Subsection 3.7.1 within fourteen days of the verbal stop payment order, provided that the RDFI notifies the Receiver of this requirement and provides an address to which the written confirmation should be sent at the time the verbal order is provided. If the RDFI requires written confirmation, the verbal stop payment order will cease to be binding after fourteen days.

For an order to stop all future payments relating to a specific authorization involving a specific Originator, an RDFI may require a Receiver to confirm in writing that the Receiver has revoked the authorization given to the Originator.

A few best practice ideas your institution may want to consider include:

For consumer stop payments issued on recurring ACH debits, contact the customer after a predetermined period of time (perhaps six months) to confirm the continuance of the stop pay order or authorize the release of the order. This option confirms with the customer they are willing to release the stop payment. It will take time and energy to send out the confirmations and to track whether the customer approves removal or wants to continue the order but it may be time well spent if a number of customers authorize release of the orders. (Subsection 3.7.1.3)
Another option is for the Bank to make a determination it will leave all consumer recurring stop payments on the system for a set period of time. The timeframes will likely vary from bank to bank. A common time period is three to five years. The Bank is accepting the risk of paying a recurring item with a stop payment placed prior to this period of time would post. If an item did post, the Bank would be responsible for the amount unless they could return the item as unauthorized within the timeframe permitted in the ACH rules.
Similar to the previous concept, the Bank will delete all consumer stop payments less than a particular dollar amount (perhaps $1,000) after a period of time (for example – one year). In this scenario the Bank will accept the risk on all recurring stop payments that are over a year old and less than $1,000 from posting to the customer’s account. If the item would post to the account, the Bank would be responsible for the dollar amount unless they would discover the item in a time period the item could be returned timely.
The last option is to leave them on the system indefinitely. If an account is closed many systems will automatically delete the stop payment order. If your system does not do this, manually cancel the stop payment request on closed account to free up storage space.

Ultimately, the decision is one Bank management needs to make, balancing the cost of monitoring stop payment requests and the residual risk to the bank in paying an unauthorized item. (March 2020)

Question: Can you please explain the ACH stop payment rule that was effective March 19, 2010? I am confused about what types of stop payment orders expire after six months.

Answer: The amended stop payment rule applies to CONSUMER accounts and brings the ACH rules in alignment with Reg. E. Stop payment orders on checks are covered by check law which provides for a six month expiration date. Whereas, stop payment orders placed on CONSUMER ACH entries do not have an expiration date. They are effective until the requested debit(s) is stopped or the customer withdraws the request, whichever is earlier. For example:

If a stop payment order is placed on a check it is covered under check law and expires in six months (no changes). This still includes RCK entries as they enter the payment system as a check the first time.
If a stop payment order is placed on a check that is used as a source document for an ARC, BOC, or POP entry it is valid until the item is stopped or the consumer revokes the order, whichever is earlier. So, a stop payment on a check expires after six months BUT the ACH rules do not have a time limit on conversion of a source document (the check) to an ARC, BOC, or POP. So, when the stop payment on the check expires after six months it can still be used as a source document. Therefore, the bank must decide how to handle this issue.
A stop payment order placed on a single-entry ACH item does not have an expiration date. It is good until the debit is stopped or the consumer revokes the order, whichever is earlier.
A stop payment order placed on all recurring ACH items does not have an expiration date. It is good until all debits are stopped or the consumer revokes the order, whichever is earlier.

Remember, these rule changes apply only to CONSUMER accounts.

Question: We have a non-Consumer (business) customer who initiated a Stop Payment order on a CCD (Corporate Credit or Debit) entry. Can this stop payment request be applied to more than one (recurring) debit entry relating to a specific authorization involving a specific Originator?

Answer: No, a Stop Payment order on a CCD entry to Non-Consumer account can only be applied to a one-time entry. NACHA operating rules state the following:

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:

The withdrawal of the stop payment order by the Receiver;
The return of the debit Entry; or,
Six months from the date of the stop payment order, unless it is renewed in writing.

The Non-Consumer customer would need to contact the Originator to revoke their authorization and if the item posts in the future it should be returned as R29 (Corporate Customer Advises Not Authorized) within the 24 hour deadline (2 banking days).

Written Statement of Unauthorized Debit

Question: Can a Written Statements of Unauthorized Debit (WSUD) be provided orally by the account holder? If yes, what would be some authentication practices for receiving a WSUD orally from an account holder?

Answer: Yes, on Sept. 17, 2021, the ACH Rules were amended to explicitly allow Receiving Depository Financial Institutions (RDFIs) to accept certain verified oral WSUDs from a customer. Subsection 3.12.4 Form of WSUD states “The Written Statement of Unauthorized Debt must be signed or similarly authenticated by the Receiver.” Authentication is the process of verifying the true identity of an individual and is a critical factor in this process. An oral WSUD may be authenticated over the phone by including codes, Personal Identification Numbers (PINs), shared secrets, etc. The signature line of a WSUD obtained over-the-phone may read something like “Bank Employee Name, verified Account Holder Name via authentication method.” If the RDFI is going to accept oral WSUDs, it would be advisable to develop written procedures to ensure account holders are consistently and properly authenticated. Procedures could also include scripted questions to ask account holders to verify their identity, including verbally stating an assertion statement in which the customer confirms the details of the WSUD are true and correct and the Receiver is an authorized signer on the account.

Question: My customer has claimed an ACH debit to their account is unauthorized and has completed a Written Statement of Unauthorized Debit. How long do I have to research the error and when do I have to give the customer credit for error?

Answer: The answer to this question is found in Regulation E and the ACH Rules. As a result, it is important to understand the interaction of the regulation and the Rules.

ACH Rules — When a customer completes a Written Statement of Unauthorized Debit, the ACH Rules state the RDFI must promptly re-credit the account with the amount deemed unauthorized. This applies if the account holder notifies the financial institution within 60 days from the Settlement Date of the transaction and the notification from the Receiver is in accordance with Section 3.12 (Written Statement of Unauthorized Debit). However, the Rules do not explicitly define “prompt.” So this is where Regulation E applies as it addresses the timing requirements for correcting a verified error (or unauthorized EFT).

Regulation E — If the customer notifies the financial institution of the disputed transaction within 60 days of the periodic statement date, Regulation E states that the financial institution must investigate to determine whether an error occurred. If it is determined that an error did occur, Regulation E states the error correction must occur within one business day after determining an error occurred. In other words, Regulation E defines “prompt” as one business day.

Therefore, when the customer signs a Written Statement of Unauthorized Debit, they are declaring an error occurred and the ACH Rules require return of the entry and provide prompt credit to the customer and no investigation is needed. The customer should be credited within one business day of the Written Statement of Unauthorized Debit being signed as the investigation is completed as soon as it is signed or similarly authenticated.

Question: Our current Reg. E error resolution procedures require the consumer to complete and sign a form describing the dispute and then document our resolution. I have found, however, that if the error was an unauthorized ACH, we only have the customer complete the WSUD form (Written Statement of Unauthorized Debt) and then we staple it to the stop pay form. Do you consider this sufficient documentation of our resolution?

Answer: First, your internal Reg. E procedures should distinguish between how to handle stop pay requests versus how to handle claims of errors. Under Reg. E and ACH rules, a stop pay request is not an “error”—rather, it’s the consumer’s request to stop the payment of a single EFT/ACH entry. Both Reg. E and the ACH rules require the customer to provide either verbal or written notification to the bank at least three banking days BEFORE the scheduled date of the transfer. The customer should sign the bank’s stop payment form—no WSUD is needed. When the ACH is presented for payment, the ACH entry may be returned using return code R08.

For unauthorized transactions, a WSUD form SHOULD NOT be completed until after the transaction posts to the customer’s account. If the transaction has not yet posted to the account and a customer informs the bank they have revoked all future transactions from an Originator, the bank must have the customer complete a stop payment request and then return any entries by that company as R08 as indicated above. Even though the R08 return code will not stop all future payments, this is the only option the bank has if a customer wishes to return an entry that has not yet posted to their account.

For TRUE ERRORS under Reg. E and ACH rules, the customer should sign the WSUD form and ACH entries should be returned using the proper ACH return codes. True error claims are those in which the customer advises the bank that the authorization for an EFT/ACH has been revoked; the customer never authorized the entry; the customer authorized the entry but for a different amount, etc. The proper ACH return code reasons include R05 Unauthorized Debit to a Consumer Account using a Corporate SEC Code; R07 for authorization revoked; R10 for unauthorized entry; and R11 Customer Advises Entry Not in Accordance with the Terms of the Authorization

As for error resolution documentation, best practice is to show compliance with Reg. E error resolution requirements by documenting:

The initial date of the customer’s notice (whether oral or in writing, and if the bank requires notice be put in writing, the date the written notice is received);
The customer’s error notice (which can be the WSUD form);
The bank’s investigation and determination if an error occurred;
The resolution of error (e.g. when either provisional or final credit was given to the customer);
The date on which the bank notified the customer of the resolution; and
If the bank determined NO error occurred, the date on which the bank provided the customer a written explanation of its findings, the right of the customer to request copies of the documents used for making the determination and, if provisional credit was given, the fact that provisional credit is being reversed and that items will be paid up to five days after the reversal if they would have paid had the reversal not occurred.

Question: A customer came into the bank today (8-13-20) and stated she has unauthorized ACH charges against her account dated from 7-1-20 thru 8-13-20 from six different companies. We are returning the entries with return code reason R10-customer advised unauthorized. I will write up a stop payment for each item. Should I attach a WSUD form, or, only if the transactions come in after today’s date?

Answer: If the transactions have already posted to the customer’s account, NACHA rules require the customer complete a WSUD form for EACH transaction in dispute (do not combine on one form). You do not have to complete a stop payment request unless the customer wishes to place a stop payment on a future ACH transaction that has not yet posted.

Reversal

Question: Our customer received an ACH deposit to her account. The very next day the originating depository financial institution (ODFI) reversed the ACH deposit and took the funds back out of the account. Of course, the customer is furious! Is the ODFI permitted to do that? What is our customer’s recourse to get the funds back?

Answer: The ACH rules permit, in certain circumstances, reversal of ACH credit entries. See the ACH Rules book at Section 2.9 – Reversing Entries:

SUBSECTION 2.9.1 General Rule for Reversing Entries – An Originator may initiate a Reversing Entry to correct an Erroneous Entry previously initiated to a Receiver’s account. The Reversing Entry must be Transmitted to the ACH Operator in such time as to be Transmitted or made available to the RDFI within five Banking Days following the Settlement Date of the Erroneous Entry.

For this Section 2.9 and Subsection 2.12.2 (ODFI Request for Return) only, an Erroneous Entry is defined as an Entry that:

(a) is a duplicate of an Entry previously initiated by the Originator or ODFI;
(b) orders payment to or from a Receiver different than the Receiver intended to be credited or debited by the Originator;
(c) orders payment in a dollar amount different than was intended by the Originator; or
(d) is a credit PPD Entry satisfying each of the following criteria:

(i) the credit PPD Entry is for funds related to a Receiver’s employment;
(ii) the value of the credit PPD Entry is fully included in the amount of a Check delivered to the same Receiver at or prior to the Receiver’s separation from employment; and
(iii) the credit PPD Entry was Transmitted by the Originator prior to the delivery of the Check to the Receiver.

The Originator must make a reasonable attempt to notify the Receiver of the Reversing Entry and the reason for the Reversing Entry no later than the Settlement Date of the Reversing Entry. For a credit PPD Entry satisfying the criteria of Subsection 2.9.1(d) above, the Originator must notify the Receiver of the Reversing Entry at the time the Check is delivered to the Receiver.
SUBSECTION 2.9.2 Indemnification for Reversing Entries
An ODFI that initiates a Reversing Entry shall indemnify each RDFI and ACH Operator from and against any and all claims, demands, losses, liabilities and expenses, including attorneys’ fees and costs, that result directly or indirectly from the debiting or crediting of the Reversing Entry to the Receiver’s account.

An ODFI cannot act on its own and reverse the entry. The originator (business initiating the ACH) must direct the financial institution to initiate a reversing entry. The originator should provide the reason for the reversal at the time the deposit was reversed or make a reasonable attempt to notify the receiver (consumer) of the reversal and reason for the reversal. Also, the entry should only be reversed if one of the situations described above as an “erroneous entry” exists. If these conditions were not met, the RDFI could report an ACH rules violation to NACHA. If the conditions were met however, the consumer should contact the originator to work out the issue, possibly in a court of law, if the consumer believes they are rightfully owed the amount.

Tax Refund ACH Processing

Question: We received an ACH tax refund payment into an account in the name of a deceased depositor. The account was owned jointly by the husband and wife but the ACH entry is in the name only of the deceased. Is this transaction subject to reclamation?

Answer: No. According to the Treasury’s Green Book, Section 5-3, tax refunds are not subject to reclamation.

Question: We received an ACH tax refund deposit into a closed account. What should we do?

Answer: The ACH Rules have specific requirements regarding availability of Credit Entries to Receivers (Subsection 3.3.1.1 and 3.3.1.2). If an ACH Entry cannot be posted due to the account being closed, it should be returned using the R02 Return Reason Code. The bank should not “reopen” the account to accept the deposit unless the consumer has initiated the process to reopen the account.

Question: What is the bank’s liability regarding tax refund direct deposits being deposited into an incorrect account? Does the bank need to check each and every incoming Treasury ACH deposit to ensure the named person on the ACH transaction is an account owner of the account to which the debit is being deposited?

Answer: The “Green Book,” which is the Financial Management Service of the Department of Treasury rules book, provides the following and can be found online at The Green Book.

The financial institution’s responsibility is to post the Direct Deposit payment to the account indicated on the ACH record. As long as the financial institution posts the payment to the account indicated, it has met its responsibility. If the funds are posted to a valid account that turns out to be the wrong account, the financial institution is not liable to the Government for the return of the funds. If the taxpayer or the taxpayer’s agent gave the incorrect account information, neither FMS nor the IRS will assist the taxpayer with recovering the funds, and the taxpayer is free to pursue civil actions. If, however, the IRS made the error, it will make the taxpayer whole.

Clearly, the IRS rule protects the bank as long as funds are delivered as directed by the taxpayer into the account designated on the tax refund. The bank does not have to check to ensure the account number designated matches the person’s name on the ACH. If the taxpayer wrote down the wrong account number, or the account number of an account belonging to another person who agreed to accept the deposit and forward payment to the taxpayer, the bank does not stand the risk of loss — the taxpayer does. It is important to note this information pertains to tax refund amounts only. If this had happened with a government benefit payment such as Social Security, the bank would stand the risk of loss and is expected to ensure the named beneficiary of the ACH is an owner of the account to which the ACH is being deposited.

Question: Do I need to verify the name matches the account number for ACH tax refunds credited to a customer’s account?

Answer: No. Per NACHA Rules Subsection 3.1.2, an RDFI (Receiving Depository Financial Institution) may rely solely on the account number contained in an entry for purposes of posting to the account, regardless of whether the name of the person on the account matches the name associated with the account number in the entry.

Question: Is an RDFI liable for an ACH tax refund deposit into an account that does not belong to the intended recipient?

Answer: No, as long as the RDFI relied upon the account number contained in the transaction as required by NACHA Rules Subsection 3.1.2. This section states an RDFI may rely solely on the account number contained in an entry for purposes of posting to the account, regardless of whether the name of the person on the account matches the name associated with the account number in the entry. Inaccurate banking information may have been supplied to the IRS by a taxpayer on his/her tax return which provided authorization for the direct deposit.

In addition, the RDFI is not liable for refunds into an account on a fraudulently filed tax return. NACHA rules Section 2.4 summarizes warranties and liabilities of ODFI’s (Originating Depository Financial Institution). Specifically, when an ODFI transmits an entry into the ACH system, the ODFI warrants the entry was authorized, the entry complied with the Rules, the entry was not transmitted on behalf of a suspended originator or third-party sender, the entry contained required information (such as the receiver’s account number and all other necessary information to enable the RDFI to properly post the entry), the credit entry was timely, and the ODFI used a secure transmission when initiating the entry. As such, the ODFI rather than the RDFI would be liable for a direct deposit made as a result of a fraudulently filed tax return.

Question: What should I do if an ACH tax refund posts to a deceased customer’s account?

Answer: Nothing. If the account is open, let the transaction post. Keep in mind tax refunds are NOT subject to reclamation. RDFIs are liable to the Federal Government for all benefit payments receive after death or legal incapacity of a recipient or death of a beneficiary. As defined within 31 CFR 210.2(h), a benefit payment is a payment for a Federal entitlement program such as Social Security, Supplemental Security Income, Civil Service Retirement, Railroad Retirement Annuity, etc. Tax refunds are not considered a benefit payment.

Question: We had a customer notify us that an ACH tax refund deposited into their account wasn’t theirs. What can we do?

Answer: Return the item R23, credit entry refused by receiver. Appendix 4, Part 4.2 of the NACHA rules manual contains a table of all return reason codes. The table provides a description of each return code, the time frame for initiating the return, as well as other information. As noted within the table, an R23 return should be used when a credit entry is refused by a receiver. The ODFI must receive the return by opening of business on the second banking day following the RDFI’s receipt of notification of refusal of the entry from its receiver, i.e. 24-hour return deadline.

Question: I am looking for guidance on ACH name mismatches. I recently read the IRS is recommending banks return any tax refund ACH deposits if the name of the taxpayer does not match the name of the account holder. Are we required to verify the owner of the account and return the funds if the account owner’s name does not match the incoming ACH record if the ACH is a tax return deposit?

Answer: NACHA rules require all Receiving Depository Financial Institutions (RDFIs) to post ACH entries based on account number. RDFIs are not required to ensure the name included with the entry is an owner on the account to which the deposit is made. In addition, Chapter 1 in the Green Book states: “3. The financial institution’s responsibility is to post the Direct Deposit payment to the account indicated on the ACH record. As long as the financial institution posts the payment to the account indicated, it has met its responsibility under the ACH rules. If the funds are posted to a valid account that turns out to be the wrong account, the financial institution is not liable to the Government for the return of the funds…” Which means it is the RDFI’s responsibility is to post the payment to the account indicated in the ACH record – same as NACHA rules.

That being said, the IRS is looking for help from financial institutions to help fight fraudulent returns. The IRS doesn’t expect RDFIs to look at every IRS payment coming in to review for a name mismatch. However, should an RDFI run across one that seems suspicious, they should consider returning it R03 (account number structure is valid, but the account number does not correspond to the individual identified in the entry).

The IRS and NACHA have partnered on an opt-in program for returning suspicious IRS tax refunds. If a financial institution has signed up for this program, they have stepped up to say they will actively look for fraudulent tax refunds. However, if the financial institution doesn’t return a tax refund which is later deemed fraudulent, they will not be liable. Again, the IRS is simply seeking help in combating this type of fraud. You can learn more about the program at https://www.nacha.org/programs/irs-refund-return-opt-program.

Same Day ACH

Question: Will Returns and Notifications of Change (NOCs) be subject to the same day ACH entry fee assessed by NACHA?

Answer: No. Returns and NOCs, whether processed same day or next day, will not be assessed the same day ACH entry fee.

Question: Can pre-notifications be initiated and settled same day? If so, are these subject to the same day ACH entry fee assessed by NACHA??

Answer: Yes, pre-notifications can be initiated and settled same day and will be assessed the same day ACH fee.

ACH Direct Access

Question: Do I have to register for ACH Direct Access if my institution does not have any direct access relationships for ACH debit transactions?

Answer: Yes. Beginning September 22, 2008, NACHA required registration from ODFIs that have direct access relationships and also required acknowledgement from ODFIs that do not maintain any direct access relationships for ACH debit transactions.

Question: Where do I register my ACH Direct Access and Third Party Sender relationships or acknowledge that I do not have any of these relationships?

Answer: NACHA has established a secure website for ODFIs that includes the forms necessary to register Direct Access and Third Party Sender relationships. Go to the NACHA secure site for Direct Access and Third Party Sender registration or to acknowledge that your Bank does not have any direct access relationships.

ACH Program

Question: We continue to be criticized during our annual ACH audit reviews because our policies do not specifically address transmission of ACH entries, storage of ACH information, and access to systems containing ACH information, nor do they address the protection of confidentiality and integrity of protected information. What exactly should we be including in our policies to satisfy this requirement?

Answer: Effective September 20, 2013, NACHA implemented new rules stating each Participating DFI must establish, implement and update, as appropriate, policies, procedures and systems with respect to the initiation, processing and storage of ACH entries that are designed to: 1) protect the confidentiality and integrity of Protected Information until its destruction, 2) protect against anticipated threats or hazards to the security or integrity of Protected Information until its destruction, and, 3) protect against unauthorized use of Protected Information that could result in substantial harm to a natural person.

Such policies, procedures and systems must include controls that comply with guidelines on access to all systems used by the DFI to initiate, process and store ACH entries. Policies should specifically address the security procedures as it relates directly to the DFI’s ACH program in order to satisfy this NACHA requirement.

Question: Can my bank charge our customers a fee for receiving and processing an IAT (international) ACH transaction since we have to conduct a manual OFAC check on each IAT ACH entry?

Answer: Yes, the bank may charge a fee to recoup costs associated with processing IAT transactions. Keep in mind that Reg. E requires the bank to provide written notice to the consumer, at least 21 days before the effective date, of any change that will result in increased fees for the consumer.

Tools

ACH Originator Annual Review Worksheet

Stop Payment vs Authorization Revoked or Unauthorized ACH