I used to do the ACH files for a large cellular provider. The thing that surprised me the most, and which you won't find by reading the spec, is that very clearly some banks present a fixed-width text field to their employees and the employee can then key in whatever the heck they want with no further validations about whether it conforms to spec when they are done. We would routinely get back returns where the reference #s to correlate back to the original transaction had obvious typos and now referenced transactions we had never sent, or where the date field was off by 1 and partially in the account field (somebody hit delete), or where the name field ran over or started early. It would always be some small bank you had never heard of, and the only conclusion I could come up with was that I needed a better manual reconciliation interface than I had expected I would to handle letters in numeric fields and fixed-width fields not starting and ending in the right place.<p>The second most surprising thing was that we'd get back returns after a full year had elapsed. Most return reasons have time limits, but banks will push through the fraud reason without apparent limit and you'd better be ready to handle it.<p>The third most surprising thing was the account verification system - you 'verify' by sending through a special transaction and waiting a week. If it hasn't returned to you after a week, must be good! I don't think anybody designing a system today would come up with such a mechanism, but that's what we have for ACH...
These write ups on ACH by the zenpayroll team are fantastic. I've had to implement similar files, like settlement files, EFT files (for Canada), etc, and they are not fun, and the various rules you have to deal with when interacting with financial institutions can really boggle the mind.<p>One institution I was dealing with had a spec for a fixed-record-length file, but when I received the file in production, they truncated it to the last non-whitespace character, which was something not in the spec.
In terms of overall n/w utility across banks from a regulator perspective ACH being quite bilateral(or multi) it seems nice, but i guess the returns part makes it look more credit-risky(for ODFI) than most multilateral netting transactions should be.Wanted to know if there are any insurance products that thrive on this very credit risk ODFI takes?<p>I haven't seen a lot of payment gateways but does ODFI place block limits or OverDraft limits on the originator and does it vary from bank to bank?
Thanks for the great series!<p>Is there any chance you could go into how you developed a relationship with your ODFI? Like how you found them, how early in your development they were willing to work with you, what type of compliance checks they required, what type of fraud prevention you guaranteed, etc?<p>This seems to be the biggest obstacle as a startup in the very early stages of exploring ACH.
Can anyone in the banking industry explain why there is no security on ACH similar to how there is for credit cards?<p>20 years ago when I first wrote a program to generate ACH files it struck me as crazy that all that was needed to take money from someones account (given an existing ACH relationship with a bank to send the file in the first place) was an individual's bank's public routing number and the individual's personal checking account number - both of which were at the bottom of every check they write.<p>I get that fraudulent charges can be reversed, but that's also true on credit cards - so why the lower security on ACH?