<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=905697862838810&amp;ev=PageView&amp;noscript=1">


SWBC's LenderHub blog is a one-stop resource for lenders.


Integrating Payment Reconciliation with Your Core


Payment processing options and consumer convenience are all the rage these days. You can barely peruse a lender trade publication or website without reading about the growth of Fintech and financial management applications and how they will ultimately affect the relationship account holders have with their financial institutions.

And, these are things we should be talking about. Technology and changing consumer expectations will have an impact on traditional financial transactions, and lenders have to be prepared to meet this consumer demand or risk losing engagement with a future generation of borrowers.

However, financial institutions should not lose sight of the implications that deploying new payment technology can have on their back-end operations, processing, and bottom line. Payment reconciliation is costly—both from an operational standpoint and a compliance standpoint—and the goal should be to streamline the settlement process as much as possible. It’s costly from an operational standpoint because of the potential associated fees: monthly/quarterly/annual service fees, transactional fees, origination fees, and merchant fees. Likewise, from a compliance standpoint, ensuring that each transaction is safe, secure, and PCI and NACHA compliant requires thorough and ongoing vendor due diligence—i.e., time.

While processing batch payments from reports is the most cost-effective way to achieve efficiency—processing a full day’s transactions only once, reducing system overhead and human error—this efficiency can be diminished if the reconciliation process is not integrated with your institution’s core.

One of the most critical operations of payment processing is the back-end settlement of funds to your borrowers’ accounts. Initially, when you launch a new payment channel, it may be okay to have a team member manually run reports and process the individual credits that have been issued to an operating account at the financial institution. However, as your payment volume increases, this approach becomes problematic for the following reasons:

  1. Human Errors: Human errors can introduce costly mistakes and customer service issues. Inevitably, when staff is manually posting transactions to accounts, human error is a concern.  Even the most experienced and diligent staff members make errors from time to time.

  2. Team Coverage: When your designated team member is unexpectedly out of office, “pinch hitters” have to step away from other duties to do this work, and they may not be as experienced as your primary processor.

  3. Timeliness: The timeliness of payments becomes constrained by a person’s ability to do the operation. As your incoming payments grow, this person will be taken away from other duties, and/or you’ll need to increase staff for this operation. Delayed or incorrect transactions on borrower accounts will cause those account holders to call or visit your credit union to have the inaccuracies resolved expeditiously.

There are several options available that can remove this manual overhead. For instance, posting files can be incorporated into your end-of-day processing routines to import transactions from a payment processing system and automatically apply the credits to the consumer accounts. These files can move faster than ACH transactions and as such, credits can be applied to your borrower’s accounts on the same day of payment.

Additionally, there are abilities to route individual ACH credits all the way down to the borrower’s loan, which can be an option when IT time is at a premium (when is it not, am I right?) and your organization has determined it’s not prudent to proceed with manual reconciliation efforts. There are two elements of this approach you must consider:

  • Since these are ACH credits, it could take up to two banking days before the credit ultimately gets applied to the account.

  • Your core ACH processing engine needs to be configured to accept this type of ACH credit. This is often a default capability; however, we’ve seen instances where configurations were needed or the ACH processing engine simply didn’t support the capability.

As a processor in the payments space, we see clients often learn to simply “live with” manual reconciliation efforts as a result of limited IT resources available to them during implementations. We encourage re-evaluating the need on, at least, an annual basis, and to make a decision to transition to automated reconciliation efforts based on where payment volumes will be next year, not where they are today. Forecasting for volumes a year out gives IT staff the ability to plan the effort, and it gives the operations team more substance on the concern, helping to raise the priority on the IT list of projects.

All of these manual processes and inefficiencies add up to a sizeable investment when you consider the time and effort spent each day. While it may require likely limited IT resources to ensure batch integration with the core, it’s time and resources well spent when you consider the monetary and more intangible expense of time over the long run when your process isn’t integrated from end-to-end, from origination to reconciliation.

This article was originally featured on creditunions.com and was edited on Feb. 13, 2017. 

New Call-to-action


Leave a comment below!