Over the past five years there has been unprecedented growth in the types of transactions that can flow through the ACH network. In fact, since 1999 the number of Standard Entry Class codes has more than doubled, to 13, excluding interbank and consumer-initiated codes.
Most of these new transaction types were created to meet specific demands for safe, secure, and low-cost transactions. But in light of new competition for electronic payments, particularly as a result of Check 21, the ACH network may need to become less complicated to remain viable.
There are multiple codes covering a consumer check that is converted into an ACH debit, also known as an e-check:
- ARC (account receivable conversion) facilitates the truncation of checks presented at the lockbox/mailbox/dropbox.
- POP (point of sale conversion) facilitates the truncation of checks presented at the point of sale.
- RCK (returned check conversion) facilitates the truncation of checks returned from a bank for re-presentment as electronic ACH items.
Next year yet another code will be introduced, BOC (back office conversion), for point of sale transactions converted in the back office. Other than monitoring of the different ways or places transactions are converted, there is absolutely no difference in the data passed from financial institution to financial institution to post these transactions.
Many companies also complain that the rules are too complicated, and that there are too many exclusions regarding which items may be converted. Can we honestly expect an 18-year-old clerk to discern whether a check is eligible for truncation at the point of sale according to the dozen or so exclusions currently required by ACH rules?
But there is more. Consumer debits or prearranged payments or deposits (PPD) make up the majority of the debits passed through the ACH network. These transactions represent both debits and credits. Typically individuals authorize companies to originate these payments with a written form. However, transactions originated by consumers through the Internet or on the telephone have their own codes, WEB and TEL.
In each case, the transaction to the recipient's account is the same; the data elements passed from bank to bank are the same.
Given the millions of dollars spent each year by banks and businesses to comply with the changes in codes, this seems all the more unnecessary.
Here are some changes that could improve the ACH network:
Eliminate standard entry class codes. We need only one code to denote a debit that was once a paper check. Let's call this CHK. All the other conversion codes could get collapsed into this code. Simultaneously, we could add a one-byte "Authorization Source" code to the file allowing all participants to know how this debit was authorized - point of sale, back office, etc. WEB, TEL, and CIE can be folded into the PPD code.
Eliminate written authorizations for e-checks. If I receive notification that my check is going to be converted into an ACH debit, then that should suffice for the merchant to do it.
Eliminate verification requirements. For certain transactions such as point of sale ones, ACH rules mandate verification of the check writer. Why mandate this? Let the merchant decide whether to check by deciding how risky a transaction is for its business or customers.
Eliminate "opt-outs." Currently, consumers or businesses can alert a merchant that they do not want their check converted into an ACH, and the merchant must process their transaction outside the system. There is no such option in Check 21. The opt-out is a limitation that seems to have been a reaction to threatened legal or legislative action, rather than reasoned functionality, and it specifically limits the growth of the ACH network.
Eliminate exceptions. Items such as credit card convenience checks, third-party checks, government checks and money orders are excluded from ACH conversion. However, any item that can be in a bank deposit can be captured as a part of a Check 21 batch and presented electronically. The ACH should have no exceptions.
To achieve even a small part of what is proposed here would take a great deal of discussion and collaboration on behalf of the system's many stakeholders.
