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

151–160 of 226 posts

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

#151

Post by kqr »

teddyh wrote: post #146
joshribakoff wrote: post #130

Earlier quoted context omitted.

Sure I don't care who wrote it if it works and passes our code review and the license matches. Plenty of crap software comes out of big name companies and plenty of random people on the street can write good code.

If you have no other alternative and can’t take the time to write it for yourself, and need something now , sure, go nuts and take something random off Github, PyPI, npm, or whatever. But code that does not have upstream development and support is dead code . A piece of code in production is like an Internet connection or electrical or water hookup – it must be, so to speak, “connected” upstream to whoever is providi…

I've always been overly eager to add dependencies to projects and while I know why it may not be good I was missing a good intuitive sense of why. This is such a good way to view it. Thanks!

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

#152

Post by tonyedgecombe »

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.

I phoned up my bank and asked them how they calculate their fees and the exchange rate on foreign transactions. Needless to say, they couldn't give me an answer.

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

#153

Post by barrkel »

kqr wrote: post #144
geomark wrote: post #99

Earlier quoted context omitted.

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…

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.

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

#154

Post by tonyedgecombe »

bct wrote: post #53
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.

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

Years ago I worked with a product that parsed line printer data, it was a nightmare trying to get every piece of optional data into the reports.

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

#155

Post by the_angry_angel »

tinbad wrote: post #62
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…

I was just going to say, working for one of the largest destributors in the world, this is still how many large corps buy stuff: by downloading a catalog through FTP and sending the order with XML. I know, shocking but not everyone is Amazon.

> I know, shocking but not everyone is Amazon.

Amazon Vendor Central only has support for EDI (at least in the UK) - as in EDIFACT files sent over FTP.

If you want to do business with them you either need to talk that or be comfortable farming out to a 3rd party (I'm 1 day into a project where I'm finding all this out, and the hell of EDI file formats).

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

#156

Post by oddsignals »

bct wrote: post #53
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.

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

What _really really_ sucks is well-defined, reasonable, meticulously documented formats where all in-the-wild implementations stray from the spec in different ways :-/

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

#157

Post by maha420 »

mjevans wrote: post #140
yellowapple wrote: post #120

Earlier quoted context omitted.

"like requiring both a password and the ssh key." That doesn't sound that unreasonable. Both satisfy the "something you know" and "something you have" portions of multi-factor authentication (respectively). Considering that this is money on the line, the idea of banks actually taking security seriously is actually refreshing. Too bad they don't seem to apply those standards to their customers.

If you can duplicate it, then it's something you know, not something you have. Everything you know in sum-total is one meta-passphrase, even if it's a combination of key-files and other data. The 'something you have' would have to be a specific hardware token (E.G. that VPN tunnel device someone else mentioned that is a black box you aren't allowed to open). Tamper resistance and physical security locks to ensure tha…

It's a key pair, for SSH keys, which is what SFTP uses to tunnel the FTP protocol. You cannot derive the private key from the public key. So no, you cannot duplicate someone's private key unless you have access to their machine. In which case you could just install a keylogger.

Hardware tokens are vulnerable too, by your own admission. A 6 digit pin created by a token is still "something you know" even if it's only good for a couple of minutes.

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

#158

Post by djmobley »

zkms wrote: post #116
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...

It's also a "push" system (and not a "pull" system like ACH) which has serious advantages -- you can send money to anyone given their sort code and account number, and those numbers do not need to be kept private. With ACH if you have someone's routing number and account number you can pull money from their account without them needing to authorise it.

In the UK there is also a 'pull' system (Direct Debit) in which you instruct your bank that a given third party can regularly take money out of your account until further notice.

It's commonplace for bill payments, subscription services, etc.

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

#159

Post by krylon »

DaiPlusPlus wrote: post #139
dmlittle wrote: post #102

Earlier quoted context omitted.

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

> 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... Depending on the business-application, fixed-width formats are fantastic because they allow for genuine O(1) random-access to records without needing t…

> I feel the only real arguments against fixed-width records are concerned with wasted space

Sometimes, fields can turn out to be too short. I have received a few letters from business with my last name truncated, because somebody way back when decided eight or nine characters are definitely enough for a surname.

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

#160

Post by rollulus »

Having spent a few years at a large energy company, I got quite used to the use of FTP servers to exchange--what else--csv files with data. And is a uploading/downloading a file to/from some ftp server really that different from POST/GETing an object to/from some REST service?

Some major news/market information provider solely made their data available to us through ftp. And used Amazon SNS to push a notification that something new is available on that ftp.

Post reply on HN