Recent news has once again exposed the reality that there are inherent risks for a third party ACH processor in handling and processing payroll transactions for a company who handles payroll for multiple companies or even a single company’s needs. 

We learned that MyPayrollHR, a company that handles payroll need for multiple companies, sent over an ACH file that contained some 26 million dollars worth of employee direct deposits to their ACH processor, Cachet Financial Services. Apparently the file was delivered just prior to a weekend and the payroll deposits were then sent out by Cachet and ultimately credited to the employees bank accounts. Unfortunately, the funding for these direct deposits either didn’t materialize or was rejected.

For some reason these payroll deposits were then debited from employee bank accounts. Evidently, this was a result of a file reversal instruction from the processor to the receiving banks. It’s difficult to understand why or how these file reversals occurred, as file reversals are supposed to be limited to incorrect transaction amounts or [the recalling] of duplicate transactions. Be that as it may, employees who worked for what was deposited in to their bank accounts had the funds withdrawn, causing quite a bit of chaos. My understanding was that the processor was to make good on those revered transactions, so hopefully all those employees have been made whole.

So how can something like this happen when direct deposit is supposed to be safe and is promoted by most all companies? 

If we look at how ACH transactions flow and what the network rules are that are involved, specifically in relation to third party ACH processors (TPP), we need to understand that the payroll files must be funded in some manor – or at least the funds should be guaranteed in some way before the payroll transactions are sent to the employees (ACH credits). A bank processing payroll can call upon a compensating balance, should their technologies allow, but a TPP must either have a reserve on account or they must first ACH debit the payroll company for the sum of all the direct deposits that will be going out via funds transfer ACH API (ACH credit). The latter incurs a time delay because there are rules around how much time can elapse for what are called a notification of return (reject). The rules are difficult to understand from what would be an employees perspective, but suffice it to say that it’s possible that a return notification can be sent and received as long as four business days after the ACH debit was originated. Keep in mind we’re talking business days, and those business days are banking business days. Banks don’t process ACH on weekends or banking holidays. 

While return notifications commonly are received faster than 4 business days, that’s the reality when a TPP takes on risks of direct deposit, at least in the scenario of funding the payroll via first debiting for the payroll amounts. So because companies and payroll vendors don’t like the wait time involved in that scenario, they must offset the risk of funding some other way. As mentioned, a reserve on hand is one such method – and each TPP will set what that amount is per client, rightly or wrongly.

In some cases a TPP might simply look at a company’s overall financial strength as a risk mitigation method, but as we all know – any company can go out of business. Bottom-line; there are risks in handling direct deposit payroll. It’s how the risks are mitigated, or perhaps more appropriately, funding guaranteed that eliminates the risks.