Live data from Hacker News

How ACH works: A developer perspective – Part 3

engineering.zenpayroll.com

11–18 of 18 posts

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

#11
post #3

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.

There are many ACH transaction types (called: SEC cods).

The post I wrote generally applies to PPD SEC codes, which are generally used when debiting a consumer bank account.

The 60-day rule applies to PPD SEC codes.

There's another ACH SEC code called CCD, which can be used when debiting a corporate bank account. For CCD codes, an 'unauthorized' return must be received within 48 hours, instead of the 60-days.

Here's a full list of ACH SEC codes:

http://en.wikipedia.org/wiki/Automated_Clearing_House

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

#13
In the case of a debit, say, is the account receiving the money always the ODFI? Can you do an ACH transfer from one client’s account at bank A to another client’s account at bank B, with you using a third financial institution to process this?

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

#15
I've done a lot of thinking in this area, mostly a few years ago when we were starting kraken.com but also ongoing.

Though the US ACH system is a particularly bad case, as others have pointed out it affects credit cards, and to a lesser extent cryptocurrencies too, and it's a global problem.

The solution is to build systems that objectively consider the real properties of these settlement networks, known or inferred, before committing to transactions.

This allows, for wont of a better term, a 'free market' in financial services that should act to increase efficiency and reduce overheads/latency worldwide by incentivising financial services companies to be more objective and transparent in their dealings.

Now: [forced to accept legalese at your bank] [try to do something at your bank] [wallow in pain and self-pity as they fail to either do anything or communicate about the flailing process]

Future: (with plugin support for arbitrary cryptographic protection, financial endpoint identification and entity identification/reputation systems) [send RFQ] [receive quotes on what you want to do, including temporal and cost overheads, references, jurisdiction information, intermediate path details, asset-types/currencies supported] [select a quote based on your local priorities, risk profiles, etc.] [execute and manage state versus promised progression with incremental status updates]

If anyone else believes this is generally logical I'd love some feedback on http://ifex-project.org/ ...

The only thing I see sort of remotely in this space right now is high end logistics solutions, of the type probably employed by SAP customers, global courier companies and places like Amazon's global warehousing.

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

#16
post #13

In the case of a debit, say, is the account receiving the money always the ODFI? Can you do an ACH transfer from one client’s account at bank A to another client’s account at bank B, with you using a third financial institution to process this?

the ODFI is always the bank that is initiating the ACH transaction, whether its a credit or debit. The RDFI is always the bank that is the target of the ACH transcation, whether its a credit or debit.

You cannot do an ACH transfer from one clients account to another clients account. You must be the originator of the ACH transaction (meaning your bank account must be at one end of the transaction).

At ZenPayroll, this is why we'll first initiate an ACH debit from the company's account to our account, wait 3 business days, and then initiate an ACH credit from our account to the employee's account.

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

#17
post #16
post #13

In the case of a debit, say, is the account receiving the money always the ODFI? Can you do an ACH transfer from one client’s account at bank A to another client’s account at bank B, with you using a third financial institution to process this?

the ODFI is always the bank that is initiating the ACH transaction, whether its a credit or debit. The RDFI is always the bank that is the target of the ACH transcation, whether its a credit or debit. You cannot do an ACH transfer from one clients account to another clients account. You must be the originator of the ACH transaction (meaning your bank account must be at one end of the transaction). At ZenPayroll, this…

This is really interesting... I currently use and administer our Intuit Online Payroll account. I'm required to run payroll only 2 full business days before pay day. Does the final credit stage you mention here not introduce any additional delay? (Read: is IOP doing the same thing to their main account?)

Also, are you or IOP able to collect interest on the 3 day float? Or does interest not accrue for not fully guaranteed funds?

Finally, is the clearinghouse account you utilize internally not something of a high-risk target? I understand there are safeguards in place to prevent unauthorized false requests, but the thought of even temporarily acting as a go between with somebody else's funds like that feels an awful lot like being a bank without the rewards.

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

#18
post #16

Earlier quoted context omitted.

the ODFI is always the bank that is initiating the ACH transaction, whether its a credit or debit. The RDFI is always the bank that is the target of the ACH transcation, whether its a credit or debit. You cannot do an ACH transfer from one clients account to another clients account. You must be the originator of the ACH transaction (meaning your bank account must be at one end of the transaction). At ZenPayroll, this…

This is really interesting... I currently use and administer our Intuit Online Payroll account. I'm required to run payroll only 2 full business days before pay day. Does the final credit stage you mention here not introduce any additional delay? (Read: is IOP doing the same thing to their main account?) Also, are you or IOP able to collect interest on the 3 day float? Or does interest not accrue for not fully guaran…

I also wonder if the account is legally set up so that employer customers get FDIC pass-through insurance.
Post reply on HN