How ACH works: A developer perspective – Part 4

http://engineering.zenpayroll.com/how-ach-works-a-developer-perspective-part-4/

by edawerd • 12 years ago

85 27 12 years ago

engineering.zenpayroll.com

pkteison• 12 years ago

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

guan2• 12 years ago

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.

mtdewcmu3• 12 years ago

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.

joncrocks• 12 years ago

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)

wmf• 12 years ago

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

whyaduck• 12 years ago

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.

wiredfool2• 12 years ago

9 track tapes. Physically couriered.

kyllo• 12 years ago

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

zrail2• 12 years ago

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)

zrail2• 12 years ago

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

edawerd3• 12 years ago

Thanks! I've updated the post.

th3iedkid• 12 years ago

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?

edawerd3• 12 years ago

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.

jeffasinger• 12 years ago

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• 12 years ago

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• 12 years ago

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?

edawerd3• 12 years ago

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.

mtdewcmu3• 12 years ago

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.

wiredfool2• 12 years ago

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.

stevewepay• 12 years ago

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.

How ACH works: A developer perspective – Part 4

Related Stories