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

~~~
jwcooper
I 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
Security would be a good reason to be slow, but I suspect that isn't the
reason.

~~~
guan
Banks 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.)

------
zrail
Part 1: [http://engineering.zenpayroll.com/how-ach-works-a-
developer-...](http://engineering.zenpayroll.com/how-ach-works-a-developer-
perspective-part-1/) (HN:
[https://news.ycombinator.com/item?id=7636066](https://news.ycombinator.com/item?id=7636066))

Part 2: [http://engineering.zenpayroll.com/how-ach-works-a-
developer-...](http://engineering.zenpayroll.com/how-ach-works-a-developer-
perspective-part-2/) (HN:
[https://news.ycombinator.com/item?id=7740967](https://news.ycombinator.com/item?id=7740967))

Part 3: [http://engineering.zenpayroll.com/how-ach-works-a-
developer-...](http://engineering.zenpayroll.com/how-ach-works-a-developer-
perspective-part-3/) (HN:
[https://news.ycombinator.com/item?id=8007838](https://news.ycombinator.com/item?id=8007838))

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

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.

------
th3iedkid
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?

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?

~~~
jeffasinger
The ODFI usually places a daily limit based on the anticipated types of
transactions, how risky your business is, how well they "know" you, and a
variety of other things.

All of that depends on the bank, and is somewhat negotiable. We had much
better luck talking to a local bank where we were able to get a meeting with
the head of the business banking division.

------
deet
Thanks for the great series!

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?

This seems to be the biggest obstacle as a startup in the very early stages of
exploring ACH.

------
kenj0418
Can anyone in the banking industry explain why there is no security on ACH
similar to how there is for credit cards?

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.

I get that fraudulent charges can be reversed, but that's also true on credit
cards - so why the lower security on ACH?

~~~
edawerd
I can't speak for NACHA (the governing body that came up with ACH), but I
believe the goal was to make it an electronic equivalent of a paper check.

If you think about it, it's pretty easy for someone to create a fake check
based on someone's account/routing number (which, as you correctly say, it's
not private information because is on the bottom of every check you write),
put it in an ATM machine and debit someone's account without their permission.
ACH is really no less secure than the current security protocol for checks.

Not that I think this is a good idea, but this might be a possible explanation
of why ACH was designed this way.

~~~
mtdewcmu
I can't use my debit card without a PIN, so I would hope that other people
cant debit my account without it. Otherwise I'd like to have the same
privilege.

~~~
IbJacked
That's just it, people _can_ debit your account with nothing more than the
routing number and account number. They can present a fake check with your
info to a seller, and it will wind its way through the entire ACH pipeline,
ending with a credit in the fraudster's account, and a debit in yours.

Hopefully, you will notice it in a timely manner and get your debit reversed.
Without action on your part, the fraudulent transaction will most likely never
be questioned.

~~~
adanto6840
It's honestly surprising to me that there haven't been more large-scale
"attacks" / frauds committed along these lines.

If anyone knows I'm genuinely curious: why hasn't it been exploited on a large
scale or what, if anything, prevents it from being exploited?

Edit: jeffasinger & edawerd largely answered my question in their posts above.

------
wmf
Mainframe-tastic. I'm surprised it's not EBCIDIC.

~~~
whyaduck
I wrote some ACH handling software a few years ago. While reading through the
200+ page spec I came to the conclusion that it was originally designed to use
fax machines as the delivery channel. Or maybe telegraphy.

~~~
wiredfool
9 track tapes. Physically couriered.

------
zrail
Small typo: 'Debit to checking account: "37"' should probably be 'Debit to
_savings_ account'.

~~~
edawerd
Thanks! I've updated the post.

