Prepaid Program Managers Take the Blame for the Problems of the ACH
March 19, 2012
If you visit web sites that enable consumers to complain about prepaid products, you will find a litany of issues that are pinned on prepaid that are actually directly related to the limitations associated with the automated clearinghouse. If there was a web site where prepaid program managers and processors could complain, I am confident it would also be dominated by the problems generated by the inability to coordinate parties involved in payments implemented over the ACH.
Easily the most common complaint from consumers are lost funds; funds that are not deposited as expected. The comedy of errors that generates this complaint starts here: a consumer directs some entity to deposit funds onto their prepaid card by identifying the prepaid card routing number and dollar amount on a form. The errors that prevent this apparently simple request to be performed are legion and yet there is almost no information that can be communicated to the consumer regarding what will happen next. They are then left with an expectation that everything will be fine and that they need to do nothing more.
Of course, in the best possible scenario they are more or less correct; funds will appear in the consumer’s prepaid account on some random day in the future. Exactly what day is impossible to indicate because it is unlikely the sender knows exactly when the funds will be sent. This is a gray area because pay cycles vary significantly from employer to employer, exact send dates often vary depending on where a particular date falls in relation to the weekend or bank holidays, the length of time it takes to traverse the ACH network can vary from same day to three days, and the time it takes for the prepaid program manager to credit the account also can vary. Sometimes the program manager will enable funds sooner by absorbing some of the ACH risk, sometimes later by waiting until good money is received and then batch updating the prepaid account at midnight or the next day. As a result, it is impossible to tell a cardholder when they will receive their funds. But that’s when everything goes right; when things go bad, it gets much worse.
Unfortunately, there are so many areas where things can go wrong it is almost impossible to document them all. Perhaps the individual entered the wrong routing number, or the routing number was transcribed incorrectly, or maybe the payee sent a small value test to make sure that the account was owned by the recipient but the recipient either wasn’t notified to look for it or forgot to respond appropriately. If the funds were from the U.S. Treasury, other problems often arise. It is not uncommon to have a mismatch between the data the program manager has on a payee versus the data the Treasury holds. When this happens, the program manager must hold the funds until the differences are rectified. Regrettably, once funds are sent, the Treasury tends to consider their job all done, and so there are very limited resources assigned to help resolve these errors. This is a huge problem for program managers since this makes it appear as if they stole the cardholder’s funds.
If everyone in the value chain knew exactly what to expect and had the ability to communicate these expectations, then many of the problems associated with the ACH could be alleviated before driving the cardholder to complain. But the ACH was designed as a bank-to-bank payment network, not as a consumer-payments network, and so it lacks any such communications capabilities.
Imagine a different scenario. Imagine if an ACH regulation required any payment going to a consumer required the originator to offer the consumer a messaging service that would notify that consumer the moment the payment was initiated on the ACH with a note that the funds should be in the consumer’s account within three-to-four days. This simple rule change could greatly reduce the problems being experienced today and make the ACH more consumer friendly. So alerted, the consumer and program manager could take corrective action much sooner in the event of an error. But there appears to be little incentive for ACH operators to address any of the issues. Since prepaid program managers take the blame, why fix the problem?