When it’s time to try something out for the first time, it’s always a good idea to give it a test run first. Heading to a new job for the first time? It’s a good idea to test driving to your new office in the morning to get an idea of traffic. The same applies to configuring new products, services, or fees in your core platform. You use the tools on hand to simulate the new fee, for example, to ensure everything will go as planned. But what about the things you set, have run successfully, and you subsequently forgot about? How often are you checking to ensure they’re running smoothly? Or maybe it’s an all new feature–did you verify it ran as expected when the time came?

Imagine this: your credit union decides to implement a newly released fee program on certain types of accounts. Member accounts should now be charged with this new fee, and you assume thanks to the high standards of quality control checks you’ve come to expect that it’s running smoothly. However, months later, a member contacts your credit union after noticing their account has not been charged the new fee the whole year. Looking at other accounts, you don’t see the fee there either. It’s configured, but it did not pay out during the month-end processing time. And just like that, your credit union has missed out on thousands of dollars in fees.

Unfortunately, I’ve seen this example happen to credit unions before. They adopt a new software for fees without putting it through the proper testing or failing to verify the results the first time it runs. So how does a credit union avoid losing money without even knowing it?

Start validating your results!

One major initiative credit unions can take to avoid this is by validating the results from software enhancements and changes their core processor releases. Developers go through a rigorous process to ensure high quality and fully functioning software. Projects spend weeks in QC. Beta releases give time to catch anything that might have been missed. But despite everything, a missed one-off scenario can slip through. This is where the end user comes in. Credit unions and their core processor should validate changes using Post-Release Validation (PRV).

The focus of Post-Release Validation is to take a closer look at these changes or enhancements to the software and identify points that could potentially negatively affect a credit union’s income statement and member relationships. These are mostly income-based changes such as fee program changes, dividend program changes, and other “back end” calculated type processes that can sometimes go out-of-sight, out-of-mind after a while. If the process fails to work and no validation was done, months can go by. If no members notice or speak up, how much money could a credit union potentially lose in that time? Not only that, but the reputation of the credit union could be compromised if a member went six months getting paid fewer dividends than they should have.

Take a closer look at fee income and dividends 

But how does a credit union accomplish PRV? Post-Release Validation can be performed by using the tools and reports already available in the core processor. For example, let’s say there is a new program that allows credit unions to charge a fee for members to have the ability to post their ACH deposit early. There are configurations to make the program work to fit their needs, however, how are the results tracked after members start utilizing it?

One option would be to review the general ledger history for the fee income g/l. Specifically, looking for any changes in the amount that is not within reason. If the fee income is $500 one month and then $110 after an enhancement or change to the way that program works, this should be a major red flag for the credit union. Catching something like this early will save a lot of time, and of course, money. A second example would be if there is a change in the background on how dividends post to member accounts at the end of the month. To validate this is working correctly after end of month, the credit union can review the general ledger history, review random member accounts, and calculate those dividends after they post to ensure accuracy, and any other reporting available to them to see drastic changes in payouts.

Don’t let your credit union lose money!

So, why else is PRV so important? It keeps the communication channels open between credit unions and their core processor on exciting new enhancements to how they run their operations. At the same time, it helps credit unions understand any software enhancements and hopefully in turn have them use the core more effectively to become more streamlined with their operations. The more you know how things are operating in the background, the more confident you can be knowing the software is working as designed.