Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

31–40 of 226 posts

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

#31
Here's a good NPR Planet Money episode on how transferring money works.

http://www.npr.org/sections/money/2013/10/04/229224964/episo...

Apparently, back in the days before ACH, banks met up at a parking lot in NYC every night and literally exchanged bags of paper checks.

There was a proposal build something better than ACH, but it was denied because the cost to upgrade the infrastructure would cost too much for small banks and credit unions.

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

#32
post #24

Today my bank sent me a note saying that ACH payments for both credit and debit cards will only take 1 day to process.

Here in New Zealand, most inter-bank transactions are cleared hourly during business hours. It's incredibly nice.

Here in Brazil, it may be a couple minutes during bank hours (10 AM to 4 PM).

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

#33
post #30

Earlier quoted context omitted.

I was referring to transfers between banks. I believe currently they go through the Federal Reserve in batches. A more distributed system could allow banks to transfer directly to/from each other in near real time.

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)

#34
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…

The number of banks in the U.S. is a legacy of President Jackson, who campaigned (and won) against rechartering the Second Bank of the United States

  https://en.wikipedia.org/wiki/Bank_War
From the founding until President Jackson's administration, debate about the extent of Federal power largely revolved around the legitimacy of a national bank. Long story short, the state sovereignty proponents won. And until very recently that victory stuck, even after the Civil War, the institution of the Federal Reserve, and the expansion of Commerce Clause powers. You didn't see any federally chartered banks until the Federal Credit Union Act of 1934, but there weren't any federally chartered banks which challenged the predominance of state chartered banks until the 1980s.

In general, and until very recently, Congress has abstained from directly regulating the banking industry. AFAIU, banks are subject to Federal law primarily indirectly via regulations promulgated by the Federal Reserve. But the Federal Reserve system is opt-in, and many smaller banks contract with larger banks to leverage the Federal Reserve transactional systems, and are therefore for the most part not subject to those rules.

It's all rather ironic because banking was one of the few areas of national commerce that was clearly contemplated to fall under federal regulatory powers, to some extent, during the time of the Constitution. Though opposed by Jefferson and Madison, the First National Bank was chartered in 1791. Yet now that federal powers have expanded to encompass every aspect of commerce, the legacy of the failure of the Second National Bank remains incredibly strong.

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

#36

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…

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.

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

#37

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.

NACHA cha cha cha!!

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

#38
I've implanted ACH file format and, worse, FedWire BAI2 file parsing… it's absolutely archaic. The worst part is that various partner banks will have differently erroneous variations of their implementation of the BAI2 spec… so we had to intentionally code buggy version to match the bugs they had on the other side… ridiculous.

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

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

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

#40

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

NACHA cha cha cha!!

You can't spell Atlach-Nacha without ACH.
Post reply on HN