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??!
How ACH works: A developer perspective (2014)
61–70 of 226 posts
Re: How ACH works: A developer perspective (2014)
#62I 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…
Re: How ACH works: A developer perspective (2014)
#63Sure, 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)
#64Earlier 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.
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)
#65Re: How ACH works: A developer perspective (2014)
#66Earlier 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.
Re: How ACH works: A developer perspective (2014)
#67Earlier 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??!
I have no idea why it is and why people are so resistant to adopting ACKs.
Re: How ACH works: A developer perspective (2014)
#68Earlier 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.)
Re: How ACH works: A developer perspective (2014)
#69I 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.
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)
#70Earlier quoted context omitted.
Wait. ACH doesn’t even tell the sender if it succeeded??!
Yeah there are no acks. It sucks.