How ACH works: A developer perspective – Part 2
engineering.zenpayroll.com
engineering.zenpayroll.com
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!
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!).
And yes, we serve the 30 banks that constitute 60% of banking volume in the US, and at least 60% of banking customers (although we suspect more, since many people who have a smaller account have a top 30 account too). We're increasing that number, but you can turn our system on so that when we don't integrate, you can still send account number and we do ACH the traditional way.
As for you not wanting to login to your online banking - you may be right! You may never do it. However, I've heard that before from a lot of people who turn right around and use Knox 30 seconds later and then become customers - so I hope you're in that group! There are some people who will be cautious, but it's actually smaller % of people than I initially thought it would be.
I would recommend configuring support for "Forward Secrecy" on both sites and enabling TLS 1.2 on thesimpledifference.com. Current score on both domains is "C".
Someday we hope to offer stored usernames and passwords as a service (making it super clear to the user that it's being authorized) but for now we only have really good security people - not "best in the world" people who would make me comfortable doing that.
Usernames and passwords are generally an all-or-nothing proposition, and will be for the foreseeable future. Is getting major banks to adopt a application-specific-password scheme [0] (maybe even with maybe-fine-grained permissions!) such a lost cause that it makes what you're proposing a vaguely reasonable thing to do?
Avg daily balance is probably the primary number. Low balance, high balance, NSFs, etc.
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).
If I understood correctly, you use the login to verify the account information and to check whether funds are available. The transfer is initiated via ACH.
Sofortüberweisung doesn't use ACH (or SEPA), they actually transfer the money via Online banking using a bot pretending to be the account owner.
Last time I paid with SOFORT I noticed that they hadn't committed the wire transfer. KLM issued me with my flight tickets, but the wire transfer was sitting in the outbox and could have been cancelled. Not sure what happens if I cancel a payment like that - does the merchant get notified and cancel the flight tickets too?
http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...
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.
Words I thought I would never hear but were in the presentation: "Fax based API"
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.
No sarcasm here at all.