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

141–150 of 226 posts

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

#141

Post by patmcc »

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.

>>>No bank has full trust of any other entity. It's not black and white.

Banks basically have full trust in each other and central banks, actually (for these kind of transactions, not investments or whatever). If you're a bank and you fuck up to the degree where you don't properly handle ACH and other transactions, guess what happens: you're no longer a bank, the government swoops in and takes over, and everything gets sorted out and you go to jail.

It works pretty well.

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

#142

Post by DaiPlusPlus »

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…

Now I finally know why my credit-union (which serves the high-technology industry exclusively) told me that they couldn't put a hold or otherwise segregate any cheques I deposit until they've cleared... because they have no way of knowing when/if they've cleared!

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

#143

Post by microcolonel »

joshribakoff wrote: post #91
microcolonel wrote: post #17

Earlier quoted context omitted.

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?

Wrote it myself because it was Elixir so why not. I'd be more careful doing this in C.

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

#144

Post by kqr »

geomark wrote: post #99
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…

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.

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

#145

Post by lucaspiller »

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…

In most of Europe (UK and IE are one exception still using SWIFT) you just need the IBAN (international bank account number). In a lot of cases the payment is instant, even between countries, and free.

Unlike the US the bank account number shouldn't be guarded with your life, so businesses often have it listed on their website.

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

#146

Post by teddyh »

joshribakoff wrote: post #130
teddyh wrote: post #115

Earlier quoted context omitted.

Whenever someone says “from github”, I mentally replace it with “from some random guy on the street” to give it its appropriate intuitive feeling.

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 providing continuous upgrades and security/bug fixes. Otherwise, it is (to continue stretching the analogy) like a mystery battery or water barrel – it could go bad in many ways at any time and you wouldn’t know it until your equipment starts to fail because of low voltage or voltage spikes, or you start to die of legionnaires’ disease. And unlike a battery or water, there are only cursory, no good and thorough, ways to test their quality, and no way to test their age as measured by the way they interact with the ever-changing outside world.

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

#147

Post by lucaspiller »

diroussel wrote: post #128
kennydude wrote: post #112

Earlier quoted context omitted.

In the UK we have "faster payments" and money these days typically appears in about 15 minutes or so

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.

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

#148

Post by Karrot_Kream »

joshribakoff wrote: post #122
Karrot_Kream wrote: post #113

Earlier quoted context omitted.

Seconding what kalleboo said, setting directory permissions has been a staple of file-sharing for decades. Setting up a node server to block read-access seems incredibly byzantine.

Good point but we also have to load balance this / have failover and provision users on the fly. I could have used messaging queues to provision PAM users on the whole cluster and this guy would have still complained because I used a non standard port. Not sure why that was a problem either but again we can't press back or question him. he would cancel the whole integration. Bottom line is our end user wanted real ti…

A lot of FTP servers have provisions to essentially "ignore" the user and proxy into the directory. As far as load balancing is concerned, most FTP servers can handle very high throughput because of the simplicity of the protocol. If you really did want to load balance it, haproxy can do that just fine.

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

#149

Post by kqr »

dragonwriter wrote: post #67
colejohnson66 wrote: post #54

Earlier quoted context omitted.

Wait. ACH doesn’t even tell the sender if it succeeded??!

NAK-but-no-ACK is apparently a super common pattern in enterprise (both internal and between parties.) I have no idea why it is and why people are so resistant to adopting ACKs.

Why it's there in the first place is fairly excusable. It (at least) halves the number of datagrams. Why people still resist it I'm not so sure about.

But on the other hand, it's a complicated architectural decision. US military wants absolutely reliable communications? They invent TCP which relies a lot on acks. Swedish telecom company wants fast and absolutely reliable communicating systems? Cue throw hands in air with a "there's no guarantees even with socks so better to simply never assume your message arrived and instead focus on detecting anomalous behaviour." They invent Erlang where there are no acks for messages.

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

#150

Post by disiplus »

diroussel wrote: post #128
kennydude wrote: post #112

Earlier quoted context omitted.

In the UK we have "faster payments" and money these days typically appears in about 15 minutes or so

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.

its still not impelemnted everywhere, in croatia the exchange between banks is happening twice a day, i believe at 12h and 17h.

alot of people here dont like to buy stuff with CC so they transfer the money with internet banking, and also get a discount because that is treated as cash, and if the webshop is with another bank you have to wait to get a confirmation they received the money, or can try to send them transaction confirmation in PDF.

sometimes its anoying when you are ordering something expenensive and have to wait a bit longer because only after your payment do they order it from the distributor.

Post reply on HN