
How ACH works: A developer perspective – Part 2 - edawerd
http://engineering.zenpayroll.com/how-ach-works-a-developer-perspective-part-2/
======
tomasien
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!

~~~
richardwhiuk
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!).

~~~
tomasien
Agreed on the SSL bit - we ask all our businesses to use it but we didn't put
it on our test site. That's embarrassing I'm putting it up now.

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.

~~~
napoleond
I don't have a US bank account so this doesn't affect me, but just speaking as
"Joe Consumer" you may want to address parent's point about the bank's T&C,
since that was the only part of his comment that jumped out at me and the only
part you didn't address.

~~~
tomasien
It doesn't. Thank you for pointing that out. Mint did a lot of the work for us
here to be honest, they made it really easy to get this stuff out of the way.

------
chadcf
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...

[http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...](http://www.npr.org/blogs/money/2013/10/04/229224964/episode-489-the-
invisible-plumbing-of-our-economy)

------
timtas
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.

~~~
EvanAnderson
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).

------
sankaetp
Please write part 3. That will be very helpful.

~~~
ericd
Seconded, this has been a great series so far.

------
rurounijones
Zen Payroll did a good presentation at Railsconf this year that touched on
this: [http://www.confreaks.com/videos/3328-railsconf-too-big-to-
fa...](http://www.confreaks.com/videos/3328-railsconf-too-big-to-fail)

Words I thought I would never hear but were in the presentation: "Fax based
API"

------
hobs
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](https://zenpayroll.com/ach_return_codes))
listed in the article, very useful bit of info, thanks!

~~~
daybreaker2
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.

------
endeavor
Very interesting, thanks! I would also be very interested in hearing some kind
of ballpark figures for the fee structure.

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
HOLY COW. Please continue. Would love to hear about the timeline mitigation.

No sarcasm here at all.

