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

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

#221

Post by mdip » Sat, Aug 26, 2017, 4:07 AM UTC

lmm wrote: post #178

mjevans wrote: post #140

Earlier quoted context omitted.

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 possible to keep an SSH key on a hardware smartcard and achieve this, no?

Yes, that's exactly how I do it with my Yubikey. Once 'moved' to the key, the private key cannot be retrieved.

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

#222

Post by jo6gwb » Sun, Aug 27, 2017, 5:35 AM UTC

ryaniscool wrote: post #192

There are several companies that provide an API on top of ACH. I work for one[1]. For high volume ACH (like a payroll company) it's usually cheaper to go through an API provider than it is to go directly through the bank. I'm not exactly sure why. Maybe because we handle technical support? We also have better reporting. One of the challenges for banks is that there is an oligopoly on the software that runs the bank.…

What is the cost per transaction? I know stripe charges 85bps.

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

#223

Post by PeterisP » Sun, Aug 27, 2017, 7:46 PM UTC

nickbauman wrote: post #39

I worked on the ACH system at the Federal Reserve Bank. When you're getting multi-gigabyte files from the Social Security Service daily that have many millions of transactions in them, you appreciate the NACHA format's compactness (~100 bytes each tx). We never transmitted files on insecure protocols like FTP, though.

I've worked on a similar system running on plain FTP (wasn't SFTP created just in something like 2000? So that it wouldn't have been an option back when the system was created) but it had no obvious security flaws because of this - all the FTP handled was the exchange of encrypted&signed files with encrypted&signed ACK messages, the same system might have been run over something like plain email.

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

#224

Post by PeterisP » Sun, Aug 27, 2017, 7:52 PM UTC

microcolonel wrote: post #20

derefr wrote: post #9

A good story on ACH: http://www.npr.org/templates/transcript/transcript.php?story... They mention that other regions' inter-bank money-transfer systems (e.g. the EU's) have been sped up to be same-day, or in some cases nearly instantaneous. The US ACH system lags behind, due to the sheer number of institutions that would be involved in a modernization effort. (There are a lot more US banks than there are UK/French/Ca…

Seems like they wouldn't need to involve everyone. Just make it semantically similar to ACH, but for some institutions clear through the new infrastructure. Even a few banks forming a coalition would be enough to make it worthwhile.

It needs to involve everyone because the only way to get there is to force them, and forcing only some of banks is kind of unfair.

E.g. the EU got there by legal limits on transaction settlement time set by the first payment services directive, the infrastructure came into place only when the banks got the message that they have to improve the product or else (IIRC the law specified that after a couple years, customers would be entitled to compensation if their payments were "too slow"). Without the requirements, EU banks would still be happy to charge 10 eur for a 3 day payment, since that's obviously more profitable than charging cents or zero for same day payments, even if the payments would be running over fast&cheap infrastructure - case in point, UK banks, which charge extreme fees for EU EUR payments simply because they, as a non-EUR country, aren't forbidden by the EU to do so.

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

#225

Post by ryaniscool » Tue, Aug 29, 2017, 2:56 PM UTC

jo6gwb wrote: post #222

ryaniscool wrote: post #192

There are several companies that provide an API on top of ACH. I work for one[1]. For high volume ACH (like a payroll company) it's usually cheaper to go through an API provider than it is to go directly through the bank. I'm not exactly sure why. Maybe because we handle technical support? We also have better reporting. One of the challenges for banks is that there is an oligopoly on the software that runs the bank.…

What is the cost per transaction? I know stripe charges 85bps.

Our pricing is typically in the range of $.05-$.35 flat fee per transaction depending on various factors. The main one being your monthly transaction volume. We have a monthly minimum of $250.

We never charge basis points but places that do might make more sense for people who have low volume and low dollar amount transactions. I would say a lot of brick and mortar businesses fall into this category.

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

#226

Post by yellowapple » Tue, Sep 05, 2017, 11:08 PM UTC

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…

"If you can duplicate it, then it's something you know, not something you have."

By this logic, a typical door key is "something you know" rather than "something you have" (never mind the uselessness of memorizing one's key shape when it comes to actually unlocking a door).

Unless you're memorizing your private SSH keys (in which case I applaud your superior intellect), it's absurd to claim that said keys fall into "something you know".