We’ll use this recipe to keep you up to date on ideas we’re discussing around ACH Exceptions processing, specifically as it relates to charging NSF and ANR (automated non-returns/courtesy pay) fees. This work was prompted by a series of communications with credit unions asking them to review their NSF and ANR procedures related to CU*BASE Tool #985 Work Daily ACH Exceptions.
Potential Enhancements to CU*BASE Tools
On 5/9/2019, a CU*Answers design team met to brainstorm on ideas for changes to CU*BASE tools and processing routines. Our main goal is to make it clearer to end-users exactly how the tools work, including warnings about what to watch out for and tips for avoiding potential pitfalls.
As a result of these preliminary conversations, developers are now starting research on several possible tracks:
Research project #1:
Stop assessing ANR fees on any re-post of an ACH exception.
Because the re-post feature currently charges ANR fees but does not NSF fees, this change would mean that a re-post would never charge a member any fee. Credit unions that wanted to assess any fees would need to do so manually in all cases.
Status as of 10/4/2019: Project #51582 was submitted; waiting for availability of programming resources.
Research project #2:
Break out ACH Exception processing into two distinct tools.
The first tool would be specifically for processing NSF exceptions. An NSF exception means the item actually attempted to post to the member’s account and was then reversed due to insufficient funds.
The second tool would be for handling all other types of unresolved ACH transactions, including invalid account numbers, frozen accounts, closed accounts, international items that failed an OFAC scan, unauthorized items and stop pays, pre-notifications, etc. All of these are items that need further attention to resolve an issue before either posting to the member’s account or returning it. This would include things like verifying against stop pay orders, correcting an invalid account number, and the like – in general, to follow CU procedures as appropriate for each exception.
The goal here would to be make it abundantly clear that the re-post feature works differently when done on an NSF item versus any other type of exception, since NSFs have already hit the account’s transaction history. And for credit unions that do not wish to monitor NSFs in any way, the tool would allow them simply to click a “return all” button to returns all NSFs with no further action. In theory, we could potentially even create a new configuration option so CUs could request us to return all NSFs without them having to even review them first, if desired.
NOTE: This project would also include the same change described in project #1, to stop posing ANR fees when items are processed via the re-post feature.
Status as of 10/4/2019: Specifications have been submitted for project #51621, which combines the ideas in #2 and #3: adding an indicator to the exceptions file to indicate why the item was an exception, and then using that indicator to split the ACH exception process into two separate tools, one for NSFs and the other for everything else. Project is awaiting availability of programming resources.
Research project #3:
Expand the ACH Exception database to include data about what happened to the item when it was first presented.
This technique would give us maximum flexibility, not only for handling exception items in a more elegant and automated way, but also when it comes to analyzing ACH traffic from a big-picture point of view. In a nutshell, when items are processed through the initial posting run, we would flag each individual item as to what happened to that item (was it NSF? Or a frozen account? Or a suspect stop pay? etc.).
That new data indicator would remain on the item while it is in the exception list, allowing the system to determine what can and should be done with it when it is re-posted. For example, if the program can tell that an item already had an NSF fee posted to it, it can avoid charging a second fee, either NSF or ANR, if it’s posted again. We could also retain that data on any transaction posted to the member’s account, for use in future data analysis tools.
Status as of 10/4/2019: See project #2 above. Additional automation and analysis options will be revisited once the core changes in that project are implemented and CUs begin using the new tools every day.
If you have thoughts or ideas you’d like to share, please leave a comment. We’d love to hear from you!