ANR and NSF Fee Enhancements
This Recipe's Chef
Got ideas for new or different ingredients? The chefs for this recipe is Dawn Moore.
Updated: October 5th 2012
There are two projects in the works aimed at helping credit unions manage the way that ANR (Courtesy Pay) fees are assessed to members. Increased occurrences of member overdrafts as well as increased scrutiny from consumer groups and legislators have put the spotlight on these and other types of fees, and credit unions are anxious to do what is right by their members, while also protecting this important source of income.
Project #1: Fees Based on Available vs. Current Balance
Currently with ANR and NSF Fee processing, CU*BASE uses the account’s available balance when determining if a debit transaction caused a negative condition on the account and thereby warranting a fee. Credit unions have expressed frustration in trying to explain to members why they are being assessed an NSF or ANR fee when there are monies in their account (the current balance is positive but the available balance is negative).
With CU*BASE Release 11.0, the account’s available balance was added to the secondary transaction description on NSF and ANR fees. While this change helped with research and explanation, we continue to have credit unions asking to have the software be able to assess the NSF/ANR fee only when the current balance goes negative, as opposed to when the available balance goes negative. These CUs believe that members should be penalized only when the actual balance is negative, regardless if the member is “playing the float” of outstanding debit card clearings.
Not all credit unions will want to change their NSF/ANR fees to be based on current balance versus available balance, as it will generally have a significant impact on fee income. Therefore the feature will be configurable. As the most challenging situations occur with debit card clearings, this phase of the project will include only the ATM/Debit Card channels. Impact on NSF/ANR Stats Dashboards
It is important to understand that with this change the system will update NSF/ANR and fee income/waiver stats based on either current or available balance. In other words, for a CU using the new Current Balance option, an item wouldn’t be considered NSF unless it dips below a CURBAL of $0, even if there were not enough available funds at the time it was presented. CUs that use this new option will see an impact not only on their fee income, but also on their historical NSF and ANR statistics, as fewer members will be flagged as having presented NSF items.
Example: John Doe has a CURBAL of $325.00 and some outstanding holds/pending transactions makes his available balance $25.00. If the CU uses the new Current Balance option, when a $300.00 item is presented John would not be charged a fee nor would the item be considered NSF, even though there were insufficient available funds, simply because the current balance would still be above $0.
(At first glance it almost seems as if using this option means that available balance no longer has any relevance. But remember that available balance is still used for authorizations, in an attempt to discourage the member spending money that’s already spoken for.)
Status: Was implemented with the 12.0 release.
Project #2: ANR Fee Caps
This project allows credit unions to set daily* maximums for the amount of ANR fees a member could potentially have to pay.
Project Assumptions
- *For the purposes of the cap, a Day = a Processing (Business) Day, measured from BOD to EOD. (A CU that runs EOD at 7:00 p.m. would have a daily clock that runs from 7pm to 7pm. Exact time of each “day” would vary, according to when that day’s processing was run. Holidays/weekends would result in a business day that might be 36, 48, or even 72 hours long.)
- Fee cap applies to ANR fees only; no change is being made to NSF fees.
- Cap will take into account all delivery channels including ATM/Debit as well as checks, ACH, teller in-house drafts, share draft force-pays, etc.
- New flag will be added at the DivApl level in NSF/ANR config, which means the cap is by product, not by origin/channel (i.e., same cap applies whether the trans comes in via ACH or Debit card or whatever).
- Cap will be by amount only, not # of fees. The current project does not include any provision for a different fee amount by channel.
- No partial fees will be posted to reach the cap. To help avoid partial fees, the config screen will prevent CU from setting a cap that is not an evenly-divisible increment of their fee amount.
- If a fee is not posted due to the cap, it will be treated exactly like any other waiver for the purposes of the Fee Income/Waiver History dashboard, member NSF history stats, and other analysis tools.
Status: In development and targeted for the 13.0 release.
Ways to Stay Connected
on Twitter
to RSS
NewsStand
also find us on facebook and LinkedIn