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

91–100 of 226 posts

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

#91

Post by joshribakoff »

microcolonel wrote: post #17
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…

I did a similar thing, but decided to have LIST/MLSD/NLST, but stub out GET/RETR/MFCT/MFF/MFMT to return nothing or static data.

What did you use to implement?

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

#94

Post by Karunamon »

joshribakoff wrote: post #87
corndoge wrote: post #28

Earlier quoted context omitted.

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

How else do you suggest you standup a sftp that cannot leak data even if the password is compromised? I'm all ears. Node is a runtime by the way and huge in what regard? The Linux codebase is also large.

First thing that comes to my mind is a PAM plugin that generates a new root directory for the user when they log in, named something sane under a fixed hierarchy. A recursive walk can later pick them all up and clean up.

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

#95

Post by djsumdog »

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…

My first job in 2005 was to take over an ACH processing system that was written for our company. It was all in Perl. :-P

ACH format is super weird .. tons of lines with 99999 on them as separators. And yes, we had to go through a bank to do any ACH transactions. They shipped us a router that setup an IPSec tunnel and it had a backup ISDN connection on it as well.

I wish ACH was more accessible. In many other countries, you give people your Name, Bank and Account number (Australia: BSB + Acct, NZ: it's one big number) and people can just send you money. Appears the next day, even on holidays. In the US we still have to photo checks with a phone app? WTF? I wrote a thing about our banking system here:

http://penguindreams.org/blog/the-american-banking-system-is...

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

#96

Post by acchow »

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.

Don't banks hold deposits at each others institutions?

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

#97

Post by joshribakoff »

dcow wrote: post #36
tomc1985 wrote: post #14

Earlier quoted context omitted.

They already have an API, it's called FTP or SFTP or whatever.

I don't know why everyone thinks they need an API to reimplement (poorly) basic unix functionality that's been around be for years.

No. I'm referring to an API to query data in realtime instead of batching the entire freaking database and then having out dated snapshot of the data

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

#98

Post by kalleboo »

joshribakoff wrote: post #87
corndoge wrote: post #28

Earlier quoted context omitted.

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

How else do you suggest you standup a sftp that cannot leak data even if the password is compromised? I'm all ears. Node is a runtime by the way and huge in what regard? The Linux codebase is also large.

Can't you just host a directory with -w- permissions? "Drop box" directories have been a staple of file sharing software for decades.

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

#99

Post by geomark »

djsumdog wrote: post #95
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…

My first job in 2005 was to take over an ACH processing system that was written for our company. It was all in Perl. :-P ACH format is super weird .. tons of lines with 99999 on them as separators. And yes, we had to go through a bank to do any ACH transactions. They shipped us a router that setup an IPSec tunnel and it had a backup ISDN connection on it as well. I wish ACH was more accessible. In many other countrie…

As an American expat living in a developing country it seems very weird to me how backwards the US ACH system is. Where I live now it's the same as the countries you mentioned, anyone can send money to your bank account using just the account number. And it appears in minutes. The banks even offer you an SMS alert when founds arrive and the sender can elect to send an SMS to alert the receiver to check their account for the received funds. Everyone uses it, including many (most?) businesses.

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

#100

Post by chomok »

This is why we need to provide better regulations for adapting better blockchain technologies in various industry sectors including this, banking. Also it's another away of sharing and saving infrastructure costs for bankings while providing better security than traditional banking systems like ACH. Perhaps ACH can be written in smart contract in safer way with security.
Post reply on HN