How ACH works: A developer perspective (2014) • Hacker News Board

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

#161

Post by digi_owl » Fri, Aug 25, 2017, 8:52 AM UTC

barrkel wrote: post #153

kqr wrote: post #144

Earlier quoted context omitted.

From what I understand, the desire for instantaneous transactions is has an inverse relation with how much money you have. Poorer countries are generally way, way ahead in mobile banking, because in a rich country you are supposed to keep around a month's salary in all your accounts, making transfers less urgent.

The way I understand it, it's a coordination issue - the bigger a market is, the longer it takes for a big change to be adopted by everyone. Plausible stories are easy to make up. Lots of countries - probably most - with higher GDP per capita than the US have lower latency banking. The US has a large proportion of people who are worse off than the equivalents in many poorer countries, too.

That, and how much existing infrastructure there is.

Many places leapfrogged directly to mobile phones (featurephones mostly) because there were little to no power and/or landline wiring present (and attempts at getting such infrastructure in place got disrupted by people stealing the wiring and selling it as scrap copper).

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

#162

Post by wiredfool » Fri, Aug 25, 2017, 9:01 AM UTC

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…

The weirdness is historical. The '9'*94 padding and the line lengths are basically holdovers from when the ACH format was constrained by the capacity of 9 track tapes.

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

#163

Post by wiredfool » Fri, Aug 25, 2017, 9:12 AM UTC

saarons wrote: post #70

ves wrote: post #61

Earlier quoted context omitted.

Yeah there are no acks. It sucks.

The lack of acks is why most companies receiving money through ACH will "season" the transactions for a set amount of time. Most of the returns occur in the first 3 business days so most seasoning periods are just around that long. The reality is you can receive a reject up until (I believe) 60 days after the transaction date. I've seen a lot of companies be a little smarter here and reduce the seasoning times for re…

It's 60 days, + some possibility of up to 2 extra days at the end for Fed Reserve holidays, and then in cases of outright fraud, occasionally banks will ignore the rules and return stuff later than that.

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

#164

Post by wiredfool » Fri, Aug 25, 2017, 9:15 AM UTC

pfarnsworth wrote: post #83

jimktrains2 wrote: post #69

Earlier quoted context omitted.

Just to be pedantic. SFTP (file transfer subsystem of SSH) or FTPS (FTP + TLS)? I mean, either is fine, I would just imagine that if it was FTP at some point, moving to FTPS wouldn't be unreasonable.

SFTP means exactly SFTP, and it's not ambiguous. FTPS is a completely different protocol.

To you, maybe. To the rest of the world, you have to check and be explicit about it.

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

#165

Post by digi_owl » Fri, Aug 25, 2017, 9:34 AM UTC

Spivak wrote: post #86

dcow wrote: post #36

Earlier quoted context omitted.

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

Especially when FTP and HTTP performance is basically comparable and will depend more on the network and storage than the protocol. Have we gotten to the point where anything not HTTP is considered old?

never mind that most "API" are JSON (or some such) delivered over (S)HTTP anyways.

But yes, anything but HTTP is "old". In large part because of corporate firewall rules that block anything but HTTP traffic (and more often than not filter even that traffic).

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

#166

Post by iagovar » Fri, Aug 25, 2017, 9:52 AM UTC

timClicks wrote: post #129

djsumdog wrote: post #95

Earlier quoted context omitted.

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…

New Zealand banks now process inter-bank payments on the same day.

1 day aprox in Spain, but depends in the bank. Some of them are quicker.

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

#167

Post by beejiu » Fri, Aug 25, 2017, 9:55 AM UTC

lucaspiller wrote: post #147

diroussel wrote: post #128

Earlier quoted context omitted.

Faster payments was mandated by the European Payment Services Directive. All European countries have it. Up next: Payment Services Directive 2 - API access to bank accounts. This is going to be interesting.

Any idea why the UK is still allowed to charge so much for outgoing Euro payments? It's reduced a lot, but my UK bank still charges £9 + their poor exchange rate.

So get another bank. This particular problem does not need regulatory intervention because there are much cheaper options available.

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

#168

Post by marktangotango » Fri, Aug 25, 2017, 10:01 AM UTC

dmlittle wrote: post #102

marktangotango wrote: post #19

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.

Every time someone complains about file formats I bring up a similar story. It's hard to believe fixed width files are still being used today. Parsing these kind of files with 45 million records, each 600+ bytes is a huge pain. I chuckle when I think about the first time I dealt with these files and thought I could open them in an editor...

Ha! I wrote an editor for fixed length files, it lets you map to a cobol copybook, or create the layout manually. I never released it. Anyone interested?

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

#169

Post by kar1181 » Fri, Aug 25, 2017, 10:23 AM UTC

Going from the UK to the US was like stepping back in time when it came to banking. I remember complaining about some aspects of UK banking - it's going to take a day for my transfer to complete!?! Now we have faster payments in the UK which complete in hours at most.

Meanwhile in the US I still had to pay my rent with a physical check because that was easier than figuring out the weird 'pay anyone' implementation my bank had.

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

#170

Post by sah2ed » Fri, Aug 25, 2017, 10:46 AM UTC

barrkel wrote: post #153

kqr wrote: post #144

Earlier quoted context omitted.

From what I understand, the desire for instantaneous transactions is has an inverse relation with how much money you have. Poorer countries are generally way, way ahead in mobile banking, because in a rich country you are supposed to keep around a month's salary in all your accounts, making transfers less urgent.

The way I understand it, it's a coordination issue - the bigger a market is, the longer it takes for a big change to be adopted by everyone. Plausible stories are easy to make up. Lots of countries - probably most - with higher GDP per capita than the US have lower latency banking. The US has a large proportion of people who are worse off than the equivalents in many poorer countries, too.

Your perspective describes the underlying issue much clearly than those who talk about "leapfrogging".

The newer platforms (like mobile banking) were adopted in those (poorer) markets because they were cheaper to deploy relative to the technology that preceeded them, and perhaps more importantly, they had less inertia to overcome (against entrenched interests).