If you find this interesting you may find the work Knox is doing pretty cool - we're able to verify funds before we make payments (so there no NSFs), get and verify account numbers without asking for the user to tell us them, and verify the identity of the payor all in one step - we just have them log into their online banking (like you do with Mint or Yodlee except faster). We've never had an ACH file returned ever, and all our payments are 100% guaranteed against everything but chargebacks as soon as they're made.
It takes away just about all these problems. We don't store usernames or passwords so there's no fraud risk there, but it does require some trust from the user to do something they're not used to, but it's super fast and easy for the user. I hope we can help solve some of these problems for developers! (Plus it's only $0.18 a payment).
If you want to try it you can donate to some cool non-profits using Knox on thesimpledifference.com - all three are worthy causes, but I think y'all will find HackCville particularly interesting. A note: the payment happens in an iFrame that is SSL secured, but thesimpledifference.com does not have SSL (currently pending). It doesn't matter really, but I know that can feel odd and 100% understand if that's offputting. Let me know if anyone has any questions!
You should fix the lack of SSL security on thesimpledifference.com
Why? iFrame SSL certificates aren't visible, and no, your VeriSign trusted doesn't count. This means users will find it offputting as you note.
Why else? Someone could hijack the HTTP page and point the iframe location somewhere else where they then intercept bank details.
Next knox only seems to support a limited number of banks, unlike ACH which I'm assuming supports alll banks.
Finally 'log into their online banking' worries me. I'd never hand over my online banking details to a third party (I suspect doing so would violate the T&Cs on my account!).
There's a payment provider doing something similar called "Sofortüberweisung" (translates to "instant (bank) transfer"). It is pretty popular in Germany, AFAIK they only support banks from Germany (and maybe some neighbouring countries).
They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN.
Quite scary to be honest, to me at least. It's basically a scraper/bot that initiates the transfer for you, pretending to be you, without the bank's knowledge. While forwarding your login information and TANs to third parties is by most banks considered a violation of their ToS, they don't seem to be willing to do anything about it (probably because of Sofortüberweisung's popularity with their customers).
I'm curious, if you don't store usernames and passwords for banking credentials, how do know if the ACH transfer will NSF? Do you ask the account holder for their bank credentials each time you want to pull money from their account?
Anybody who made a donation or started a donation on thesimpledifference and has feedback about UX (or otherwise) issues they had and could email me at tommy at knoxpayments dot com I would just love to hear from you so much you have no idea.
Planet money also did a podcast on this and went into a bit of how the ACH system works (not from a development point of view). It's a very strange system and honestly the episode raised more questions than it answered but it seems there is a lot of secrecy behind how it all works. Also why it all works... The fact that it can take 3-5 business days to transfer money electronically between different banks in the same country is difficult to grasp, but they make an effort to explain why...
My first job out of college in 1987 was a COBOL programmer working on the Unisys version of the ACH system. There were two versions, IBM and Unisys, which were mandated to maintain 100% feature parity. The reason for two versions was that the Federal Reserve System preferred not to sole-source mainframes across its 12 districts.
To understand ACH it helps to understand that it's basically electronic checks. The FRB system was (and is) the nation's clearing house for physical checks. The people who created ACH took as their model the existing system of check processing.
By the time I started, a goodly portion of inbound files came over a wire, but many (if not most) still came on magnetic tapes delivered each day by couriers. A few years earlier all files had come as magnetic tapes and (I believe) before that, punch card decks.
The biggest risk, and the thing we lived in fear of -- and I suppose they still do -- is a "delayed file." If a file cannot be processed by the promised time because of an error in the ACH system, then the receiving accounts are not credited when they are due. This results in "float" -- interest lost. This can reach into the millions, and when the Federal Reserve is at fault, they have to eat it.
The post talks a lot about rejections. In my day, the largest most complicated program was the "The Editor" which had only one job: to reject files. This beast took the form of a three inch thick green bar printout which I would remove from a hanging file folder each day. If memory serves, about 1 out of 10 lines was GO TO. I could wax on, but suffice to say, this drove me out of programming for 12 years.
When I saw this post, I had to wonder if any of the code I wrote so long ago is still running today.
Having worked with Unisys-based financial software in the early 2000's (A Series MCP-based stuff) I can only assume that code you wrote is probably still running. There is a serious commitment to legacy compatibility there (for better or for worse).
I have written exports from various payroll systems to produce NACHA compliant ACH files to upload to banks, every time there was a problem the bank would get back to us through the customer and we would get super weird or vague responses.
In the future I am going to ask for the return codes ( https://zenpayroll.com/ach_return_codes) listed in the article, very useful bit of info, thanks!
Writing NACHA exports for an online banking loan repayment system was the worst. Being a Junior Dev at the time, and having my only guidance being a NACHA handbook, with no banking experts to actually explain things, knowing millions of dollars per year would go through the app... Man. Terrifying.
[+] [-] tomasien|12 years ago|reply
It takes away just about all these problems. We don't store usernames or passwords so there's no fraud risk there, but it does require some trust from the user to do something they're not used to, but it's super fast and easy for the user. I hope we can help solve some of these problems for developers! (Plus it's only $0.18 a payment).
If you want to try it you can donate to some cool non-profits using Knox on thesimpledifference.com - all three are worthy causes, but I think y'all will find HackCville particularly interesting. A note: the payment happens in an iFrame that is SSL secured, but thesimpledifference.com does not have SSL (currently pending). It doesn't matter really, but I know that can feel odd and 100% understand if that's offputting. Let me know if anyone has any questions!
[+] [-] richardwhiuk|12 years ago|reply
Why? iFrame SSL certificates aren't visible, and no, your VeriSign trusted doesn't count. This means users will find it offputting as you note.
Why else? Someone could hijack the HTTP page and point the iframe location somewhere else where they then intercept bank details.
Next knox only seems to support a limited number of banks, unlike ACH which I'm assuming supports alll banks.
Finally 'log into their online banking' worries me. I'd never hand over my online banking details to a third party (I suspect doing so would violate the T&Cs on my account!).
[+] [-] pfg|12 years ago|reply
They go a step further and actually transfer the funds from your bank account via Online banking after you provide them with your login and TAN.
Quite scary to be honest, to me at least. It's basically a scraper/bot that initiates the transfer for you, pretending to be you, without the bank's knowledge. While forwarding your login information and TANs to third parties is by most banks considered a violation of their ToS, they don't seem to be willing to do anything about it (probably because of Sofortüberweisung's popularity with their customers).
[+] [-] edawerd|12 years ago|reply
[+] [-] tomasien|12 years ago|reply
[+] [-] chadcf|12 years ago|reply
http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...
[+] [-] timtas|12 years ago|reply
To understand ACH it helps to understand that it's basically electronic checks. The FRB system was (and is) the nation's clearing house for physical checks. The people who created ACH took as their model the existing system of check processing.
By the time I started, a goodly portion of inbound files came over a wire, but many (if not most) still came on magnetic tapes delivered each day by couriers. A few years earlier all files had come as magnetic tapes and (I believe) before that, punch card decks.
The biggest risk, and the thing we lived in fear of -- and I suppose they still do -- is a "delayed file." If a file cannot be processed by the promised time because of an error in the ACH system, then the receiving accounts are not credited when they are due. This results in "float" -- interest lost. This can reach into the millions, and when the Federal Reserve is at fault, they have to eat it.
The post talks a lot about rejections. In my day, the largest most complicated program was the "The Editor" which had only one job: to reject files. This beast took the form of a three inch thick green bar printout which I would remove from a hanging file folder each day. If memory serves, about 1 out of 10 lines was GO TO. I could wax on, but suffice to say, this drove me out of programming for 12 years.
When I saw this post, I had to wonder if any of the code I wrote so long ago is still running today.
[+] [-] EvanAnderson|12 years ago|reply
[+] [-] sankaetp|12 years ago|reply
[+] [-] ericd|12 years ago|reply
[+] [-] nickh|12 years ago|reply
[+] [-] jaequery|12 years ago|reply
[+] [-] rurounijones|12 years ago|reply
Words I thought I would never hear but were in the presentation: "Fax based API"
[+] [-] hobs|12 years ago|reply
[+] [-] daybreaker2|12 years ago|reply
[+] [-] endeavor|12 years ago|reply
There's one problem I've wanted to solve, and thought ACH might be able to help, but really didn't know where to start. This has been very helpful.
[+] [-] lucasisola|12 years ago|reply
No sarcasm here at all.