Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How ACH works: A developer perspective – Part 3

engineering.zenpayroll.com

Post reply on HN
Print view View original

1–10 of 18 posts

Re: How ACH works: A developer perspective – Part 3

#3

Post by waps »

hayksaakian wrote: post #2

Good read. The most interesting fact to me was that it takes 3 days to 100% confirm a transaction. I thought bitcoin was slow, but this really gives me hope.

Technically it takes 60 days. Not sure from what basis. I would assume that 60 days countdown only starts on the 2nd or 3rd day, so that would make it 63 days.

Re: How ACH works: A developer perspective – Part 3

#4

Post by wiredfool »

waps wrote: post #3
hayksaakian wrote: post #2

Good read. The most interesting fact to me was that it takes 3 days to 100% confirm a transaction. I thought bitcoin was slow, but this really gives me hope.

Technically it takes 60 days. Not sure from what basis. I would assume that 60 days countdown only starts on the 2nd or 3rd day, so that would make it 63 days.

   "... no later than the opening of business on the banking
   day following the sixtieth calendar day following the   
   settlement date of the original entry"
From my notes, quoted from the NACHA spec a few years back.

So, settlement date is the next day (mostly). + 60 days, then the next morning that banks are open. So, if 60 days is Thursday, Christmas Eve, then the next Monday morning is the cutoff.

Re: How ACH works: A developer perspective – Part 3

#5

Post by zaroth »

It's interesting how the incentives are misaligned for the two banks. The receiver wants to wait as long as possible before returning a REJECT, because returning earlier doesn't benefit them, and in fact can hurt the customer experience.

My bank will send me a warning that an ACH is pending, and I need a certain amount in the account by 10am the next morning. That's plenty of time to move funds into place from a neighboring account (as long as it doesn't involve selling shares). And on the other hand, it's an interesting benefit that the requester of the debit doesn't see this happening.

I think the solution is an explicit ACK. We could add an optional pingback url as part of each transaction message, and let everyone else deal with building the infra.

I have a feeling it's a lot more complicated than that. $39 trillion a year is a lot of transactions to track live status for, so I suspect this is both complicated and valuable.

What the heck NACHA -- impress us with your ability to build the next gen ACH system! Oh right, unless we're talking a physical structure, that's never going to happen.

Re: How ACH works: A developer perspective – Part 3

#7

Post by wyager »

hayksaakian wrote: post #2

Good read. The most interesting fact to me was that it takes 3 days to 100% confirm a transaction. I thought bitcoin was slow, but this really gives me hope.

>I thought bitcoin was slow

I don't know what standard people are using to reach this opinion.

Credit card:

• Transaction goes through to pending state within 5-30 seconds. Chargeback is easy in this state.

• Transaction is fully confirmed in 60 days.

Bitcoin:

• Transaction goes through to pending state within 1-2 seconds. Chargeback may be possible in this state.

• Transaction is fully confirmed in a few minutes.

Re: How ACH works: A developer perspective – Part 3

#9

Post by donutz »

"the RDFI is allowed 60 days to return the ACH debit. Because of this, the ACH protocol is very consumer friendly, since the originator of the ACH debit must now return the money they debited"

Well, consumer-friendly if the consumer has enough money in their account to temporarily cover the unauthorized debit amount plus any other authorized debits/withdrawls that occur in the meantime. But if the ODFI's do their homework to keep fraudsters from getting accounts, I suppose that issue is minimized.

Re: How ACH works: A developer perspective – Part 3

#10

Post by anactofgod »

The details you provide are especially interesting, especially in light of PayPal's announcement yesterday of their Next-Day-Settlement (NDS) service: http://thenextweb.com/insider/2014/07/08/paypal-now-lets-us-...

NDS must be a proprietary alternative to ACH.

Thanks for this write-up. Looking forward to your next post on the ACH file format.

Post reply on HN