How ACH works: A developer perspective – Part 4 | Hacker News Reader

How ACH works: A developer perspective – Part 4

engineering.zenpayroll.com

85 pointsedawerd27 comments

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

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.

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.

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

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

Security would be a good reason to be slow, but I suspect that isn't the reason.

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

I 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

(source: I implement financial IT stuff in the US, UK and Europe)

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

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

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

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.

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?

I haven't seen any insurance products that thrive on the risk that ODFI takes, but the ODFI does minimize their risk by requiring the originator to keep a collateral account to which they'll take money from should they incur any kind of loss.

The ODFI does place daily (soft) limits on the originator, and the amount of collateral you have to put up is proportional to your daily limit. It definitely varies from bank to bank and is a largely of a factor of how much your bank trusts you and your past ACH history with them.

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.

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.

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?

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.

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.

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.

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.

The banks have built fraud detection to handle this, I had to handle the case of somebody attempting to cash several hundred thousand dollars worth of faked cheques in a past job. The bank stopped them before they cleared.

What's more interesting to me is the police and FBI's complete disinterest in going after the perpetrators even though they knew who they were.

As far as I can tell the security is 2 fold:

  * transactions are reversible for quite a long time. 
  * ODFIs (originating banks) are responsible for files they send.

A bad actor can get away with stuff for a while, but sooner or later, their ODFI will cut them off. Those relationships take time to build, so you don't want to be going through them quickly. And there are often deposits and other security protecting the ODFI.

So, the customer says it'sfraud. It's not their bank's problem, they punt to the ODFI. The ODFI is in the business of not taking too much risk, so they yank money from the originator. The Originator, they might be SOL, depending on if they're the one who was scammed, or if they have a way to reclaim the money.

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

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.

9 track tapes. Physically couriered.

The fixed-width positional flat file format is definitely a COBOL thing. I work at a company that uses a very similar format as input messages to a COBOL batch-processing system that used to run on HP mainframes (but has since been ported to Solaris SPARC hardware).

Small typo: 'Debit to checking account: "37"' should probably be 'Debit to savings account'.

Thanks! I've updated the post.

Reply on news.ycombinator.com