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

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

#191

Post by EpicEng » Fri, Aug 25, 2017, 1:27 PM UTC

joshribakoff wrote: post #119

EpicEng wrote: post #101

Earlier quoted context omitted.

>Because it didn't work in FileZilla, they didn't want to use it Sounds like they didn't need much if any of what you did. They wanted X and you gave them Y. Y would require them to change the way they worked. Did they need query capability? Seems like they didn't and SFTP would have suited them better. Honestly sounds to me like you went for an overly complex solution where something simple would have done just fine…

Our company and their company have a common customer. Neither of us need each other we want to make our customer happy. Customer would be happiest with realtime data but company B wants to send snapshots via sftp. So I setup an endpoint that speaks sftp. They even told me to "do something" to make it secure. Then they complained I used a port other than 22 and that it only worked on the command line. It sounds like t…

Fair enough, I didn't have the backstory.

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

#192

Post by ryaniscool » Fri, Aug 25, 2017, 1:35 PM UTC

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. There are 4 companies that provide the "core banking" software to most of the banks in the USA. The banks get stuck providing you with whatever services one of these four pieces of software is capable of.

[1] http://acheck21.com/api/

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

#193

Post by jdmichal » Fri, Aug 25, 2017, 1:38 PM UTC

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…

The major US banks created clearXchange to solve this problem, which was later sold and now rebranded to Zelle. It's near-instantaneous transfers for supported banks, and only needs a phone number or email address. (I think it's quaint in comparison that you need to give out your bank account number for other systems. Holding of account numbers is exactly the problem that modern mobile wallets worked so hard to solve with tokenization.)

https://en.wikipedia.org/wiki/ClearXchange

I consider it a huge marketing failure that this is such a little known capability.

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

#194

Post by jdmichal » Fri, Aug 25, 2017, 1:49 PM UTC

rollulus wrote: post #160

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 tha…

I used a SOAP service once, which had a single string-typed element. In that element went some XML, encoded as an XML string. I found out later that the original version used FTP drops, and all they did is wrap the FTP'd file as a string in the SOAP request.

So no, sometimes there's very little difference between the two. FTP is just another way to send data over a network. I mean, you could even write a custom FTP server that read the file directly into processing instead of dropping it on a file system and reading it from there in some other process.

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

#195

Post by h0undawg » Fri, Aug 25, 2017, 1:52 PM UTC

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…

not necessarily SFTP, always FTP in some form in the US. I have seen FTPS, I have also seen banks just use FTP by default without encryption (shocking? not really).

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

#196

Post by joncrocks » Fri, Aug 25, 2017, 1:56 PM UTC

jdmichal wrote: post #193

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…

The major US banks created clearXchange to solve this problem, which was later sold and now rebranded to Zelle. It's near-instantaneous transfers for supported banks, and only needs a phone number or email address. (I think it's quaint in comparison that you need to give out your bank account number for other systems. Holding of account numbers is exactly the problem that modern mobile wallets worked so hard to solve…

The difference is, however, that you can assign a bank account a number that is unique within a given banking system.

Once you move into the realm of trying to tie an identifier you have no control over (and that has no reliable verification method for) to a place where money will go, you open yourself up to a smorgasbord of potential attack vectors, confusions and edge cases.

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

#197

Post by [deleted] » Fri, Aug 25, 2017, 2:04 PM UTC

oddsignals wrote: post #156

bct wrote: post #53

Earlier quoted context omitted.

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 :-/

[deleted]

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

#198

Post by lojack » Fri, Aug 25, 2017, 2:06 PM UTC

bct wrote: post #50

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…

Even calling it archaic is too harsh. Granted, the batch-centric nature is not ideal (and it's hard to imagine a system with this kind of latency built in being designed today), but if you're designing a system based on batch processing then shipping files over SFTP is a pretty reasonable way to do it.

SFTP tends to be the go-to method of integrating software between organizations, especially ones that aren't used to building actual APIs. It's standardized, everyone knows how to use it, and it essentially boils down to: generate a file and upload it to a server. There's all sorts of problems with it, and it tends to be a pretty short sighted decision.

The biggest problem I've found is that there's no real feedback loop (for this class of integration, not sftp specific). Company A uploads a file -- often in the middle of the night -- and Company B processes that file some time later. Could be a minute, could be a day. Company B fails to process the file, possibly because of a change on their end, possibly because of a change on Company A's end. There's usually a bunch of back and forth, but ultimately the earliest you can determine if a fix works is a full 24 hours after the file was initially dropped. Both companies could create integration environments with shorter feedback loops to help, but ultimately its a problem of not getting an immediate response that the integration is working.

95% of my job involves writing software to integrate systems from different companies, and the integrations that involve SFTP are almost always the biggest pains. I've thought about writing an SFTP server that operated in real time, and either rejected bad files or had some other way of responding to the inputs. Never really found the time to do it, and ultimately it'd be patching a process that should have just been a well designed API from the start.

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

#199

Post by perlgeek » Fri, Aug 25, 2017, 2:20 PM UTC

tannhaeuser wrote: post #117

FWIW, Swift (the company behind the interbank payment system) has been developing and pushing ISO 20012 as an XML-based long term replacement for their Swift message format, though it's not designed as a replacement for ACH. For that, there was HBCI years ago (also XML); don't know if it's used much still.

If I remember correctly, HBCI is often used for consumer banking software to get account data from the bank.

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

#200

Post by jdmichal » Fri, Aug 25, 2017, 2:22 PM UTC

joncrocks wrote: post #196

jdmichal wrote: post #193

Earlier quoted context omitted.

The major US banks created clearXchange to solve this problem, which was later sold and now rebranded to Zelle. It's near-instantaneous transfers for supported banks, and only needs a phone number or email address. (I think it's quaint in comparison that you need to give out your bank account number for other systems. Holding of account numbers is exactly the problem that modern mobile wallets worked so hard to solve…

The difference is, however, that you can assign a bank account a number that is unique within a given banking system. Once you move into the realm of trying to tie an identifier you have no control over (and that has no reliable verification method for) to a place where money will go, you open yourself up to a smorgasbord of potential attack vectors, confusions and edge cases.

Bank account numbers are not unique across banks. Account number schemes aren't even uniform across banks. The only limitation is what fits within the ACH system. You need the combination of routing number (to identify the bank) and account number (to identify the individual within the bank).

Zelle associates the bank account to a email address and / or phone number. Creation of these associations is gated through the member banks. So you have all the controls you have for any other banking task.