It is good to mention that it also a very similar system in Canada for EFT. I did implementation of that.
How ACH works: A developer perspective (2014)
41–50 of 226 posts
Re: How ACH works: A developer perspective (2014)
#42The UK's Faster Payments system does same day (often less than an hour) inter-bank transfers for up to £250,000.
http://www.fasterpayments.org.uk/about-us/how-faster-payment...
Re: How ACH works: A developer perspective (2014)
#43I 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.
Re: How ACH works: A developer perspective (2014)
#44Earlier quoted context omitted.
Which is a bit like saying, at least the 70mph mountain pass road has a guard rail.
Well, if not TLS, then what would you use? Noise? TLS is the only widely deployed standard cryptographic protocol which has ever protected any internet communication to any degree. For its many flaws and patchwork, there is nothing even competing in the category.
There is ssh.
Actually sftp (ssh) tends to be a lot more popular than FTPS (TLS) because of the whole FTPS NAT catastrophe that sftp doesn't have.
Re: How ACH works: A developer perspective (2014)
#45I 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 archaic, but takes the headline's shock value down a small peg[1].
[0] It adds a mental pause -- a Secure ... FTP server. It hints that, possibly, it's a reference to a different aspect of the server's security (a non-technical person might refer to a server as being a "secure" server simply because it's protected by an ID and password, for instance).
[1] Based on my personal interaction with banks and software, as well as several friends who had previously been members of a few banks' IT departments, my first -- very sarcastic thought -- was "of course it works that way!"
Re: How ACH works: A developer perspective (2014)
#46I 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.
Most i've seen use Connect:Direct Secure Plus
Re: How ACH works: A developer perspective (2014)
#47I had an integrator request this so I stood up a nodeJS server that only implements upload, not download. This way if they leaked their own password, a malicious actor is limited to forging data, and no real data can be leaked. Because it didn't work in FileZilla, they didn't want to use it. Worked at another company that shuffled data between big name gyms & health insurance companies, it also used CSV files sent ov…
Wouldn't FileZilla have been happy with a fake blank directory response?
Re: How ACH works: A developer perspective (2014)
#48I 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.
Same here when I worked at a Mortgage company. SFTP everywhere.
Re: How ACH works: A developer perspective (2014)
#49Re: How ACH works: A developer perspective (2014)
#50I 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…
Even calling it archaic is too harsh. Granted, the batch-centric nature is not ideal (and it's hard to imagine a system with this kind of latency built in being designed today), but if you're designing a system based on batch processing then shipping files over SFTP is a pretty reasonable way to do it.