Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

Post reply on HN
Print view View original

51–60 of 226 posts

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

#51

Post by fragsworth »

Lazare wrote: post #26
tomschlick wrote: post #13

The exciting thing about all these crypto currencies to me, is that banks could roll their own private "exchange" currency to do near real time transfers to any other bank / account.

> banks could roll their own private "exchange" currency to do near real time transfers to any other bank If only US banks already had access to some sort of shared currency they could use for such transfers! Snark aside, this just seems like a horrible use for a crypto currency. Block chains are an interesting tool to solve a lack of trust when you're willing to give up some speed and convenience. Banks have full tr…

No bank has full trust of any other entity. It's not black and white. They use ratings (either Standard and Poor's or others) to determine the risk involved in a liability. Even the U.S. Government has a certain amount of risk.

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

#52

Post by jlgaddis »

While "part 1" of this series says "FTP" (implying plain-text/unencrypted data), "part 2" [0] and "part 3" [1] both say "SFTP". This is "more correct", in my experience, as encryption is pretty much always used nowadays.

[0]: http://engineering.gusto.com/how-ach-works-a-developer-persp...

[1]: http://engineering.gusto.com/how-ach-works-a-developer-persp...

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

#53

Post by bct »

marktangotango wrote: post #19
joshribakoff wrote: post #6

I 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…

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)

#54

Post by colejohnson66 »

posguy wrote: post #18
joshribakoff wrote: post #6

I 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…

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??!

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

#55

Post by donatj »

tomschlick wrote: post #13

The exciting thing about all these crypto currencies to me, is that banks could roll their own private "exchange" currency to do near real time transfers to any other bank / account.

But why use banks at all then?

If I don't have to worry about the physical cash, there's no real reason for me to use a bank. They're a hanger on of a bygone era.

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

#56

Post by colejohnson66 »

microcolonel wrote: post #20
derefr wrote: post #9

A good story on ACH: http://www.npr.org/templates/transcript/transcript.php?story... They mention that other regions' inter-bank money-transfer systems (e.g. the EU's) have been sped up to be same-day, or in some cases nearly instantaneous. The US ACH system lags behind, due to the sheer number of institutions that would be involved in a modernization effort. (There are a lot more US banks than there are UK/French/Ca…

Seems like they wouldn't need to involve everyone. Just make it semantically similar to ACH, but for some institutions clear through the new infrastructure. Even a few banks forming a coalition would be enough to make it worthwhile.

The problem is that no businesses want to spend money to fix something that isn’t broken. It’s the reason XP (or earlier!) is/are still around; “Why should we spend money updating to Windows 7 when 2000 works just fine?”

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

#57

Post by donatj »

mdip wrote: 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…

Is it sftp or ftps? They're very different things and I am fairly certain it's the latter.

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

#58

Post by sigjuice »

oso2k wrote: post #48
nickbauman wrote: post #39

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.

Same here when I worked at a Mortgage company. SFTP everywhere.

Did they use sftp from the OpenSSH package or was it some sort of commercial variant?

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

#59

Post by colejohnson66 »

donatj wrote: post #55
tomschlick wrote: post #13

The exciting thing about all these crypto currencies to me, is that banks could roll their own private "exchange" currency to do near real time transfers to any other bank / account.

But why use banks at all then? If I don't have to worry about the physical cash, there's no real reason for me to use a bank. They're a hanger on of a bygone era.

Because if you forget your bank password, you can reset it. If you forget your password to your private key, you’re SOL.
Post reply on HN