Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

61–70 of 226 posts

Re: How ACH works: A developer perspective (2014)

#61
post #18

Earlier quoted context omitted.

ACH needs to die. Its a very old system, and you have no clue if a transfer ever actually goes through. Only ACH rejects ever get sent back, and there isn't a definitive window in which you'll get that reject.

Wait. ACH doesn’t even tell the sender if it succeeded??!

Yeah there are no acks. It sucks.

Re: How ACH works: A developer perspective (2014)

#62
post #45

I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…

I was just going to say, working for one of the largest destributors in the world, this is still how many large corps buy stuff: by downloading a catalog through FTP and sending the order with XML. I know, shocking but not everyone is Amazon.

Re: How ACH works: A developer perspective (2014)

#63
For us and our bank it's gpg encrypted and then transferred over SFTP.

Sure, the ACH file format is sort of sucky, but it's not like it's difficult. The lack of an ACK is super awful tho. Payroll has to call in 20m after sending to verify.

Re: How ACH works: A developer perspective (2014)

#64
post #30

Earlier quoted context omitted.

A centralised system would also "allow banks to transfer directly to/from each other in near real time"

That wouldn't be "direct", it would be through a trusted third party... Who has banking hours, could censor the transaction, etc.

That shouldn't be an issue if all parties trust the Third party.

It is only an issue if there is sufficient lack of trust that the involved fear such a thing would happen.

Otherwise a block chain is overkill.

Re: How ACH works: A developer perspective (2014)

#66
post #30

Earlier quoted context omitted.

A centralised system would also "allow banks to transfer directly to/from each other in near real time"

That wouldn't be "direct", it would be through a trusted third party... Who has banking hours, could censor the transaction, etc.

Fiat currency REQUIRES the trust of the central bank, so that's not an issue.

Re: How ACH works: A developer perspective (2014)

#67
post #18

Earlier quoted context omitted.

ACH needs to die. Its a very old system, and you have no clue if a transfer ever actually goes through. Only ACH rejects ever get sent back, and there isn't a definitive window in which you'll get that reject.

Wait. ACH doesn’t even tell the sender if it succeeded??!

NAK-but-no-ACK is apparently a super common pattern in enterprise (both internal and between parties.)

I have no idea why it is and why people are so resistant to adopting ACKs.

Re: How ACH works: A developer perspective (2014)

#68
post #53

Earlier quoted context omitted.

Funnily, you're complaining about csv formatting, guess you never worked with ACH formatting. It's cobol fixed length files. I implemented parsing/creation for this file format at two different companies. Hired on at one company, first day, my manager said, "hey, you have experience with ACH right? we have this project...". That's when you learn to start leaving stuff off your resume.

You can do a lot worse than ACH. It's hard to read, but it's simple and pretty well-defined. What _really_ sucks is one-off fixed-width formats that aren't well defined, or that change suddenly (oh, you thought that field would always be populated? lol no.)

Yeah, ACH is surprisingly not-unpleasant, at least relative to nightmares like X12 EDI with its implicit looping constructs and billions of companion guides that supercede random parts of the base spec.

Re: How ACH works: A developer perspective (2014)

#69
post #43

I worked on the ACH system at the Federal Reserve Bank. When you're getting multi-gigabyte files from the Social Security Service daily that have many millions of transactions in them, you appreciate the NACHA format's compactness (~100 bytes each tx). We never transmitted files on insecure protocols like FTP, though.

Every bank I've worked with uses SFTP rather than FTP.

Just to be pedantic. SFTP (file transfer subsystem of SSH) or FTPS (FTP + TLS)?

I mean, either is fine, I would just imagine that if it was FTP at some point, moving to FTPS wouldn't be unreasonable.

Re: How ACH works: A developer perspective (2014)

#70
post #61

Earlier quoted context omitted.

Wait. ACH doesn’t even tell the sender if it succeeded??!

Yeah there are no acks. It sucks.

The lack of acks is why most companies receiving money through ACH will "season" the transactions for a set amount of time. Most of the returns occur in the first 3 business days so most seasoning periods are just around that long. The reality is you can receive a reject up until (I believe) 60 days after the transaction date. I've seen a lot of companies be a little smarter here and reduce the seasoning times for repeat users using the same source bank account. It is a fascinating system to work with every day. Wire transfers are their own bundles of fun too.
Post reply on HN