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

71–80 of 226 posts

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

#71

Post by jlgaddis »

corndoge wrote: post #28
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…

why use a huge codebase like node for such a simple security critical task

When all you have is a hammer...

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

#72

Post by paulie_a »

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.

Previously I had no experience with ACH but my current project is essentially reverse engineering a very proprietary version of NACHA and another file that is 400 fields long. Honestly the current parser does work but I can only assume due to some black magic or other voodoo.

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

#73

Post by [deleted] »

donatj wrote: post #57
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.

[deleted]

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

#74

Post by matt_wulfeck »

pryelluw wrote: post #12
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…

Ugh, reminds me of the time I had to integrate with a bunch of school software. They used csv over ftp (no auth). You just had to connect to the server and get the personal information of a district's students. Worse is you could google the URLs... I built a system that solved the problem but left shortly after it began to be integrated nationwide.

wait.. are you saying that a district had public ftp with personal student information? Pretty sure that breaks the law.

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

#75

Post by kyrra »

donatj wrote: post #57
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.

Most payment vendors are on SFTP at this point. Very few still use only FTPS. But then they do silly things with SFTP, like requiring both a password and the ssh key.

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

#76

Post by emodendroket »

fragsworth wrote: post #51
Lazare wrote: post #26

Earlier quoted context omitted.

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

We're talking about whether transactions are legitimate and not the creditworthiness of the institutions.

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

#78

Post by kyrra »

jackgavigan wrote: post #42

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

Faster payments was able to work because the UK gov forced them to do it. The UK has the advantage of having a few very large banks (unlike the US that had around 15,000 different banks). The government was able to get the dozen or so banks to work together and get same day ACH working.

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

#80

Post by mdnormy »

sigjuice wrote: post #58
oso2k wrote: post #48

Earlier quoted context omitted.

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?

Just sharing mine. My company customer consist of major international financial establishment.

As some simply can't go with certain open source project due to compliance, we settled with Tectia SSH[1]. Similar story with VPN and other security-related stuff.

Everything is SFTP with them. Even API json response lol

1. https://www.ssh.com/products/tectia-ssh

Post reply on HN