3 ms·
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 clea
by pkteison 12y ago
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.
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.
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...
- guan 12y agoA lot of services verify by making those two random <$1 deposits and having customers enter the amounts in, then withdrawing them immediately. This appears to be faster than the verification system. The first business I encountered that used the “real” verification system was Fidelity, and I found that quite annoying.
- mtdewcmu 12y agoBanks frustrate me, and I don't think there is any technological excuse. I suspect the systems are antiquated and they are not motivated to change. They use security as a cover for their slowness.
- toomuchtodo 12y agoIn the US, banks are all owners of the Automated Clearing House, and every time a vote comes up to modernize it, they don't get a majority vote because they sell products to "move" money faster at a much higher premium: http://www.npr.org/blogs/money/2013/10/04/229224964/episode-489-the-invisible-plumbing-of-our-economy http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...
- jwcooper 12y agoI think security, and maybe more so stability are very valid reasons for banks to move slowly on these systems. It may appear archaic from the outside, but these systems are pushing $39 trillion dollars a year (22 billion transactions) [1]. I can see why the big banks are hesitant to change things drastically. [1] https://www.nacha.org/ach-network/timeline https://www.nacha.org/ach-network/timeline
- mtdewcmu 12y agoSecurity would be a good reason to be slow, but I suspect that isn't the reason.
- guan 12y agoBanks are conservative, too. Which is generally good, but that in itself is part of the reason why the process is slow, in addition to genuine concerns about security and reliability. In some ways security isn’t such a big deal for financial transactions, because they can be undone. Checks are very insecure. ACH is insecure because you can take money out of anyone’s account with the information at the bottom of the check, but ACH transactions can be reversed for at least 45 days after they are made. You also have to ask “how much?” How long is it reasonable to wait for change? The system for same day ACH has existed for years. Very few banks have opted in. Should the Fed set a deadline and say, everyone has to be on it by 2020? (It’s the nature of such deadlines that they are be extended, but something will eventually happen.)
- joncrocks 12y agoI think the most interesting thing is that each bank is left to interpret the 'spec' in it's own way. This leads to situations as you describe, where you can easily get junk from your ODFI/RDFI. I say 'spec' because it's a very large book that's successful in not being very specific. AFAIK, there's no automatic way of tracing a claim to it's subsequent rejection, outside of doing it yourself. You would have thought that would be basic. And yes, pre-notes are slightly hilarious. In europe, we're moving towards SEPA - http://en.wikipedia.org/wiki/ISO_20022 http://en.wikipedia.org/wiki/ISO_20022 (source: I implement financial IT stuff in the US, UK and Europe)