11 ms·

How ACH works: A developer perspective

179 points by edawerd 12y ago

jesusmichael 12y ago
ACH libraries have been around for 20 years... Hope you didnt recreate the wheel...
- r00fus 12y ago
  Any good ones you'd recommend for major languages?
  - jesusmichael 12y ago
    Technically... You cant initiate an ACH transaction. You request it from a member institution, who authorize and initiate it. Many large institutions have their own APIs... But cybersource http://www.cybersource.com/developers/ http://www.cybersource.com/developers/ has most of what you'd need
    - r00fus 12y ago
      Interesting - as I understand the process is generally to send an ACH file to a bank's file transfer point once agreements are signed and credentials/keys are shared. Are there any libraries to create the ACH file itself from basic information like ODFI, etc?
      - aioprisan 12y ago
        There are a few good ones on GitHub: https://github.com/jm81/ach https://github.com/jm81/ach At my old company, we manually had someone use ACH Tools to build out these files, upload to the bank's interface, etc.: http://www.achtools.com/HomePage.aspx#!/ http://www.achtools.com/HomePage.aspx#!/
- mclarke 12y ago
  ...if only financial institutions actually adhered to the NACHA specification :(
  - wiredfool 12y ago
    Right. 94 character, fixed width. What could go wrong there? What's that, you want line endings? I've seen \r, \n, and \r+\n. Nothing like 96 characters in a 94 character format.
    - dragontamer 12y ago
      Why the were you voted down?
      - wiredfool 12y ago
        Sarcasm, I think.
      - dang 12y ago
        https://news.ycombinator.com/item?id=7619287 https://news.ycombinator.com/item?id=7619287
r00fus 12y ago
Great intro to a near-ubiquitous payment format (in the US - outside the US, it looks like ISO 20022 [1] is taking over). I'm looking forward to seeing details about payment confirmation/rejection, and possibly stuff about automated wire transfers (so-called "high value payments" in payment-geek parlance). For those of you who are just coming into the Finance space, I found this site to be very helpful in getting your feet wet [2]. Anyone have other resources they've found useful/informative? [1] http://en.wikipedia.org/wiki/ISO_20022 http://en.wikipedia.org/wiki/ISO_20022 [2] http://www.accountingcoach.com http://www.accountingcoach.com
- contingencies 12y ago
  http://www.scribd.com/doc/215642587/Finance-and-the-Future-Beyond-Bitcoin http://www.scribd.com/doc/215642587/Finance-and-the-Future-B...
- rahimnathwani 12y ago
  If you want to learn about accounting from fundamentals up, I recommend Frank Wood's Business Accounting 1: http://www.amazon.co.uk/gp/aw/d/0273712128?pc_redir=1398115582&robot_redir=1 http://www.amazon.co.uk/gp/aw/d/0273712128?pc_redir=13981155... For more advanced topics, the 3rd party study guides for the major accounting qualifications are pretty good. Try searching Amazon for 'BPP CIMA'. Note: these are resources focused on accounting. If you are interested in finance, then you could do worse than starting with Brealey & Myers: http://www.amazon.co.uk/dp/B00DDML9U2 http://www.amazon.co.uk/dp/B00DDML9U2
joezydeco 12y ago
If you don't want to wait for part 2, NPR had a decent podcast about how the current American ACH system works, and why it hasn't moved out of the 1960s: http://www.npr.org/blogs/money/2013/10/04/229224964/episode-489-the-invisible-plumbing-of-our-economy http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...
- BallinBige 12y ago
  good podcast. its apparent that the ACH network is considering intra-day settlements and with Check 21 as an option, money can be moved/settled quicker
- ForHackernews 12y ago
  The main reason it hasn't moved out of the 1960s is it works pretty damn well. It's a bit slow, but money goes where it needs to go, and there's a good audit trail to trace in cases of fraud.
  - Touche 12y ago
    It's crazy slow. Most ACH moves through a modern stack and then into COBOL that runs nightly batch jobs that then update the stuff in the modern stack and in on its way. Nevertheless, it takes the nightly batch job.
    - ForHackernews 12y ago
      Honestly though, they processed 22 billion payments totaling 38.7 trillion dollars in 2013.[0] When you're dealing with numbers like that, there's an argument to made in favor of battle-hardened COBOL batch processing over some real-time rewrite. [0] http://www.prweb.com/releases/2013/ACH_Volume/prweb11740323.htm http://www.prweb.com/releases/2013/ACH_Volume/prweb11740323....
  - deathanatos 12y ago
    One of my banks, every night between the hours of 12 am and 6 am America/Chicago (local), notes that they are processing the day's transactions or something, and my balance might not be correct. I presume they're handling ACH transfers during that time. That said, during that time, my balance has read any of the previous day's balance, the next day's balance after processing all pending transactions, $0.00 (this one is particularly worrisome), and amounts that cannot be obtained by adding any combination or subset of the day's pending transactions. And that's not mentioning that the uptime for this is effectively 75%, assuming nothing is going wrong. It could be faster. I could enjoy not having to worry that I might lose vast quantities of money because somebody got the number that I both must keep secret and give to everyone I do business with. I could wish for bank websites that understood how SSL works. Yes, for what it does, perhaps it "works pretty damn well". But the requirements have changed since 1960.
bostik 12y ago
This made me cringe: > Your [bank] will set you up with a secure FTP server onto which you’ll upload ACH files. Automated financial transactions, with lots of money involved. Secure. FTP server. Of course I know that FTP is still considered "secure" for some business applications but this is absurd. With all the security (mis)features the banks have put forward with card payments in order to shift liability to account holders, the very core of inter-bank transactions then runs on something as insecure as FTP. The shoemaker's children have no feet.
- lisper 12y ago
  > This made me cringe As well it should. But it gets worse. Much, much worse: http://blog.rongarret.info/2010/11/personal-banking-nightmare.html http://blog.rongarret.info/2010/11/personal-banking-nightmar... It often amazes me that the U.S. financial system works at all.
  - pjg 12y ago
    Maybe. Here's a slightly different perspective. First take the case of ftp'ing/sftp'ing files to a bank. There are multiple layers of security in sftp - not just the username and password. Source IP is checkec in a stateful way so spoofing is hard even if one somehow manages to get the credentials. Furthermore the files will not be processed unless there is an out-of-band message (typically an email, could be a phone call too ) with certain info also required in very specific format which must match the contents of the file. So there you go. 3 layers of security with one layer being completely out-of-band with the other two is reasonable enough for the risk involved. (There are other measures hard coded e.g. a dollar limit which basically "cap" any fraud but I won't go into those) Now for the missing (or atleast MIA) transaction you allude to on your blog: Just because you were not told how the money ended up where it did doesn't mean people didn't know. Bankers are steeped in "social engineering" and trained from day one to only give out information required by law and really nothing else. Whether you use Fedwire or Swift (or really any other RTGS = real-time gross settlement network ) there is always a trail. Always. In your case it was probably Fedwire - and the bank I'm guessing was BofA or maybe Chase. Regardless if the sender's account is an individual account (not business) they are still protected by Reg E (as well as FDIC insurance). Reg E as you may know basically puts the onus of returning the funds to the sender's account on the bank. The problem is the timelines or the lack of it. Since banks are generally allowed upto 30 days (I don't know if 30 days is hardcoded ) in law they take their sweet time in tracing. And when they find out - they almost always do - they deliberately will not share details with you to protect themselves from liability. The bottom line is ACH/FedWire moves trillions of dollars - hundreds of billions a day - and barring a very small percentage they all work.
theflyingkiwi42 12y ago
Just curious. How hard is it for a bank to agree to be your “Originating Depository Financial Institution"? We currently use Balanced for ACH payouts, but it sounds like we could actually do this ourselves and significantly speed up the process as well as cut down on fees.
- wiredfool 12y ago
  It varies depending on your risk profile and how much the bank wants to do your transactions (dollar volume of deposits matter, and fees). If you're coming in as a customer, it may just be a matter of being a commercial customer and paying enough fees. If you're trying to come in as a third party processor, it's more involved. Relationships help there. You might need significant volume (hundreds or more per day) to make it worth switching from Balanced to something else for outgoing payments. With enough volume (10k+/month), you might get under .10/transaction. Balanced doesn't seem like they're particularly slow about outgoing payments. (from a quick scan of their site) The slowness comes from the ACH network where nothing is ever confirmed settled, it just hasn't come back returned yet.
  - theflyingkiwi42 12y ago
    My main issue with Balanced is that since I don't use them to collect payments, it takes forever to get the money moved to them. And it is a manual process. So every Monday morning I get a file with payments. I have to move that amount over to Balanced. This can take 3 to 5 business days, but almost always takes 5 or even 6. Meaning I cannot pay my customers until the Friday (5 days) or the Monday (8 days) later. Also, Balanced cannot process ACH for payments from clients. Having to verify an account with micro deposits is simply not workable for our clientele, many of which do not want to take credit cards because of the high fees. While our volume right now is too low, it is interesting info to have, and something I'll look into further. Thanks!
    - wiredfool 12y ago
      Basically, anything that's not next business day is a delay due to risk. (well, except for online bill pay, which can be printed checks that are mailed out.) Depending on the risk profile of the business, we've done an array of things from 0 day simultaneous ACH credits and debits to 3 or more day holds on incoming funds (via ACH) before credits can go out. Obviously, the riskier the business, the more expensive it is to go fast. 3 day holds are pretty common, since any NSF sort of return is supposed to happen in that time frame.
dkarapetyan 12y ago
So they use FTP and files as an RPC mechanism. What happens when you accidentally overwrite files? How does sequencing happen? Do they use timestamps on the files? It sorta, kinda makes sense and I can't really deny the simplicity of the whole scheme.
- edawerd 12y ago
  I'm sure every bank has their own protocol, but ours requires us to datestamp and incrementally sequence our filenames.
- wiredfool 12y ago
  Generally, there's a confirmation step for transaction counts and file totals. Also, there's something of a convention to never send the same file name twice.
martin_ 12y ago
Seems very logical, not much to learn in part 1! Does the ACH still hit the federal reserve if the two accounts are at the same bank?
- wiredfool 12y ago
  Maybe, depends on the bank. It certainly doesn't have to if the bank is optimally processing the file.
  - BallinBige 12y ago
    there is a lot of discussions and actions being made for intra-day settlements.
    - logicalmind 12y ago
      Yep, here are the current details: https://www.nacha.org/news/nacha-leads-industry-toward-ubiquitous-same-day-ach-settlement https://www.nacha.org/news/nacha-leads-industry-toward-ubiqu...
      - BallinBige 12y ago
        IMO - this is the only way ACH can remain competitive with Card transactions. Intra-day settlements and returns
        wiredfool 12y ago
        Speeding up returns will be a nice bonus, though there's still a long window for fraudulent returns that can really bite.
        logicalmind 12y ago
        The whole payment space is getting really interesting in the last couple of years. Banks and retailers trying to work around credit card processing fees as they became larger part of their balance sheets.
SkyMarshal 12y ago
Good start. Would love to see what an actual ACH file looks like. Googling returns some specs and the like, but not sure if any contain the exact doc that gets FTP'd to the Fed.
- logicalmind 12y ago
  If you google for an example "nacha file" instead of an "ach file" you should be able to find what you're looking for. Here is one example of what one looks like: http://www.treasurysoftware.com/ach.html http://www.treasurysoftware.com/ach.html
logicalmind 12y ago
If you want to get into the nitty gritty of the format of ACH/NACHA files you can buy the spec here: https://www.nacha.org/nacha-estore-rules https://www.nacha.org/nacha-estore-rules But you can find parts of the book online at various places. Many financial institutions support NACHA files, but you'll also find many that violate the spec. I happen to have implemented a C# NACHA implementation recently and it wasn't a lot of fun. And there is a huge difference between ACH receipt and ACH origination.
jarrett 12y ago
So, an entity that's set up with an ODFI can initiate arbitrary debits to arbitrary accounts, with no action by the owner of the debited account. What happens if that privilege is abused? Is it like chargebacks with credit cards? What if the debit is so small the victim doesn't notice?
- logicalmind 12y ago
  There is a strict system in place for violating the rules: https://www.nacha.org/NSfines https://www.nacha.org/NSfines But if things occur on accident, there is a "Returns" process for handling it. It looks like the author intends to cover that, at least partially, in the next installment. Here is a list of return codes if you want a hint: http://www.mainstreetmerchantsolutions.com/ach-return-codes http://www.mainstreetmerchantsolutions.com/ach-return-codes
- notdonspaulding 12y ago
  There are all sorts of policy-based resolution methods in the ACH world. But there is nothing technologically restricting arbitrary debits/credits to arbitrary accounts in arbitrary amounts. One policy meant to deal with this is called "Velocity limits" which is basically a rate-limit of how much the OFDI will underwrite your account for. i.e. You can debit up to $50,000/day and then your OFDI will cut off further ACH transactions until some of your outstanding ones have settled. Another policy is that (for Check21 checks processed via ACH anyway) the checking account owner has up to 60 days from the statement date to dispute the charge, meaning the ACH transaction can be reversed up to 90 days after it was initiated. It's straight out of the 60's. And on one hand, it's cool that everybody uses this system and nobody notices how old it is. On the other hand, it's freaky when you realize that every time you swipe a debit card or write a check, you've basically handed over all the credentials needed for that person to debit your account as much as they like (until they're discovered). Also, remember that automatic deposit implies automatic withdrawal. ACH systems are by far the craziest API integrations I've ever had to do.
chicagomint 12y ago
"documentation explaining the ACH system is targeted towards bankers, not software developers." The ACH system itself is designed for the benefit of bankers, not developers, or even depositors. Bitcoin alleviates the need for the excesses of the described system.
- dedward 12y ago
  Bitcoin doesn't let me withdraw US $ from one US bank account and deposit it in another US bank account in bulk. Bitcoin lets me transfer bitcoin around - which is fantastic and wonderful - but it doesn't address the problem at hand.
  - scotty321 12y ago
    You don't understand. Once you're in the Bitcoin ecosystem, you don't necessarily need to backtrack out into US $ anymore. I buy almost everything with Bitcoin, and shop at Bitcoin-friendly stores. Except for grocery stores. I don't know of any grocery stores yet that accept Bitcoin in my area, but they will surely arrive someday.
deleted 12y ago
[deleted]
weishigoname 12y ago
seems logical
clintcparker 12y ago
I've integrated with several domestic ACH APIs, and none of them are FTP based. Most are SOAP services.
mikesickler 12y ago
Is there no getting around debiting party A into your own account, then crediting party B from your own account? Is it not possible to initiate a direct payment from A to B?
jordanbaucke 12y ago
Obligatory "Bitcoin will disrupt this" post.
- hafichuk 12y ago
  Not in our lifetime. Cryptocurrencies will just be another bolt on and thing we need to integrate. The upshot is that the banks probably won't manage this. The downside is that the banks probably won't manage this.
vinhboy 12y ago
I hope you guys continue with this series and make the next one more in-depth. I am very curious how everything work, especially the fees.
edoceo 12y ago
I too was in finance. Had to write ACH processing for loan payments and collection. No fun. However, there are plenty of docs from the Fed. No test systems tho :(. I think I'll go look for some of my old ACH code just for fun.
perlpimp 12y ago
"moves electronically through the banking system today" I assume only in United States? I wonder if one can automate SWIFT transfers the way one does ACH, that would be epic.
scotty321 12y ago
THIS is why Bitcoin. THIS.
ipince 12y ago
What are the fees? Random question: is this how Dwolla does its transactions--through ACH?
BlueStar 12y ago
I'm an ACH product manager who's worked the user side of ACH for years, and I've never seen a conversation like this. It's amazing. Even though most of it went off on a file-transfer tangent, I've picked up some really interesting tips. Like, I never imagined there would be stuff about ACH on GitHub. BTW, ZenPayroll is an amazing product and I want to work there.

179 points by edawerd 12y ago

jesusmichael 12y ago

ACH libraries have been around for 20 years... Hope you didnt recreate the wheel...

r00fus 12y ago
Any good ones you'd recommend for major languages?
- jesusmichael 12y ago
  Technically... You cant initiate an ACH transaction. You request it from a member institution, who authorize and initiate it. Many large institutions have their own APIs... But cybersource http://www.cybersource.com/developers/ http://www.cybersource.com/developers/ has most of what you'd need
  - r00fus 12y ago
    Interesting - as I understand the process is generally to send an ACH file to a bank's file transfer point once agreements are signed and credentials/keys are shared. Are there any libraries to create the ACH file itself from basic information like ODFI, etc?
    - aioprisan 12y ago
      There are a few good ones on GitHub: https://github.com/jm81/ach https://github.com/jm81/ach At my old company, we manually had someone use ACH Tools to build out these files, upload to the bank's interface, etc.: http://www.achtools.com/HomePage.aspx#!/ http://www.achtools.com/HomePage.aspx#!/
mclarke 12y ago
...if only financial institutions actually adhered to the NACHA specification :(
- wiredfool 12y ago
  Right. 94 character, fixed width. What could go wrong there? What's that, you want line endings? I've seen \r, \n, and \r+\n. Nothing like 96 characters in a 94 character format.
  - dragontamer 12y ago
    Why the were you voted down?
    - wiredfool 12y ago
      Sarcasm, I think.
    - dang 12y ago
      https://news.ycombinator.com/item?id=7619287 https://news.ycombinator.com/item?id=7619287

r00fus 12y ago

Great intro to a near-ubiquitous payment format (in the US - outside the US, it looks like ISO 20022 [1] is taking over). I'm looking forward to seeing details about payment confirmation/rejection, and possibly stuff about automated wire transfers (so-called "high value payments" in payment-geek parlance). For those of you who are just coming into the Finance space, I found this site to be very helpful in getting your feet wet [2]. Anyone have other resources they've found useful/informative? [1] http://en.wikipedia.org/wiki/ISO_20022 http://en.wikipedia.org/wiki/ISO_20022 [2] http://www.accountingcoach.com http://www.accountingcoach.com

contingencies 12y ago
http://www.scribd.com/doc/215642587/Finance-and-the-Future-Beyond-Bitcoin http://www.scribd.com/doc/215642587/Finance-and-the-Future-B...
rahimnathwani 12y ago
If you want to learn about accounting from fundamentals up, I recommend Frank Wood's Business Accounting 1: http://www.amazon.co.uk/gp/aw/d/0273712128?pc_redir=1398115582&robot_redir=1 http://www.amazon.co.uk/gp/aw/d/0273712128?pc_redir=13981155... For more advanced topics, the 3rd party study guides for the major accounting qualifications are pretty good. Try searching Amazon for 'BPP CIMA'. Note: these are resources focused on accounting. If you are interested in finance, then you could do worse than starting with Brealey & Myers: http://www.amazon.co.uk/dp/B00DDML9U2 http://www.amazon.co.uk/dp/B00DDML9U2

joezydeco 12y ago

If you don't want to wait for part 2, NPR had a decent podcast about how the current American ACH system works, and why it hasn't moved out of the 1960s: http://www.npr.org/blogs/money/2013/10/04/229224964/episode-489-the-invisible-plumbing-of-our-economy http://www.npr.org/blogs/money/2013/10/04/229224964/episode-...

BallinBige 12y ago
good podcast. its apparent that the ACH network is considering intra-day settlements and with Check 21 as an option, money can be moved/settled quicker
ForHackernews 12y ago
The main reason it hasn't moved out of the 1960s is it works pretty damn well. It's a bit slow, but money goes where it needs to go, and there's a good audit trail to trace in cases of fraud.
- Touche 12y ago
  It's crazy slow. Most ACH moves through a modern stack and then into COBOL that runs nightly batch jobs that then update the stuff in the modern stack and in on its way. Nevertheless, it takes the nightly batch job.
  - ForHackernews 12y ago
    Honestly though, they processed 22 billion payments totaling 38.7 trillion dollars in 2013.[0] When you're dealing with numbers like that, there's an argument to made in favor of battle-hardened COBOL batch processing over some real-time rewrite. [0] http://www.prweb.com/releases/2013/ACH_Volume/prweb11740323.htm http://www.prweb.com/releases/2013/ACH_Volume/prweb11740323....
- deathanatos 12y ago
  One of my banks, every night between the hours of 12 am and 6 am America/Chicago (local), notes that they are processing the day's transactions or something, and my balance might not be correct. I presume they're handling ACH transfers during that time. That said, during that time, my balance has read any of the previous day's balance, the next day's balance after processing all pending transactions, $0.00 (this one is particularly worrisome), and amounts that cannot be obtained by adding any combination or subset of the day's pending transactions. And that's not mentioning that the uptime for this is effectively 75%, assuming nothing is going wrong. It could be faster. I could enjoy not having to worry that I might lose vast quantities of money because somebody got the number that I both must keep secret and give to everyone I do business with. I could wish for bank websites that understood how SSL works. Yes, for what it does, perhaps it "works pretty damn well". But the requirements have changed since 1960.

bostik 12y ago

This made me cringe: > Your [bank] will set you up with a secure FTP server onto which you’ll upload ACH files. Automated financial transactions, with lots of money involved. Secure. FTP server. Of course I know that FTP is still considered "secure" for some business applications but this is absurd. With all the security (mis)features the banks have put forward with card payments in order to shift liability to account holders, the very core of inter-bank transactions then runs on something as insecure as FTP. The shoemaker's children have no feet.

lisper 12y ago
> This made me cringe As well it should. But it gets worse. Much, much worse: http://blog.rongarret.info/2010/11/personal-banking-nightmare.html http://blog.rongarret.info/2010/11/personal-banking-nightmar... It often amazes me that the U.S. financial system works at all.
- pjg 12y ago
  Maybe. Here's a slightly different perspective. First take the case of ftp'ing/sftp'ing files to a bank. There are multiple layers of security in sftp - not just the username and password. Source IP is checkec in a stateful way so spoofing is hard even if one somehow manages to get the credentials. Furthermore the files will not be processed unless there is an out-of-band message (typically an email, could be a phone call too ) with certain info also required in very specific format which must match the contents of the file. So there you go. 3 layers of security with one layer being completely out-of-band with the other two is reasonable enough for the risk involved. (There are other measures hard coded e.g. a dollar limit which basically "cap" any fraud but I won't go into those) Now for the missing (or atleast MIA) transaction you allude to on your blog: Just because you were not told how the money ended up where it did doesn't mean people didn't know. Bankers are steeped in "social engineering" and trained from day one to only give out information required by law and really nothing else. Whether you use Fedwire or Swift (or really any other RTGS = real-time gross settlement network ) there is always a trail. Always. In your case it was probably Fedwire - and the bank I'm guessing was BofA or maybe Chase. Regardless if the sender's account is an individual account (not business) they are still protected by Reg E (as well as FDIC insurance). Reg E as you may know basically puts the onus of returning the funds to the sender's account on the bank. The problem is the timelines or the lack of it. Since banks are generally allowed upto 30 days (I don't know if 30 days is hardcoded ) in law they take their sweet time in tracing. And when they find out - they almost always do - they deliberately will not share details with you to protect themselves from liability. The bottom line is ACH/FedWire moves trillions of dollars - hundreds of billions a day - and barring a very small percentage they all work.

theflyingkiwi42 12y ago

Just curious. How hard is it for a bank to agree to be your “Originating Depository Financial Institution"? We currently use Balanced for ACH payouts, but it sounds like we could actually do this ourselves and significantly speed up the process as well as cut down on fees.

wiredfool 12y ago
It varies depending on your risk profile and how much the bank wants to do your transactions (dollar volume of deposits matter, and fees). If you're coming in as a customer, it may just be a matter of being a commercial customer and paying enough fees. If you're trying to come in as a third party processor, it's more involved. Relationships help there. You might need significant volume (hundreds or more per day) to make it worth switching from Balanced to something else for outgoing payments. With enough volume (10k+/month), you might get under .10/transaction. Balanced doesn't seem like they're particularly slow about outgoing payments. (from a quick scan of their site) The slowness comes from the ACH network where nothing is ever confirmed settled, it just hasn't come back returned yet.
- theflyingkiwi42 12y ago
  My main issue with Balanced is that since I don't use them to collect payments, it takes forever to get the money moved to them. And it is a manual process. So every Monday morning I get a file with payments. I have to move that amount over to Balanced. This can take 3 to 5 business days, but almost always takes 5 or even 6. Meaning I cannot pay my customers until the Friday (5 days) or the Monday (8 days) later. Also, Balanced cannot process ACH for payments from clients. Having to verify an account with micro deposits is simply not workable for our clientele, many of which do not want to take credit cards because of the high fees. While our volume right now is too low, it is interesting info to have, and something I'll look into further. Thanks!
  - wiredfool 12y ago
    Basically, anything that's not next business day is a delay due to risk. (well, except for online bill pay, which can be printed checks that are mailed out.) Depending on the risk profile of the business, we've done an array of things from 0 day simultaneous ACH credits and debits to 3 or more day holds on incoming funds (via ACH) before credits can go out. Obviously, the riskier the business, the more expensive it is to go fast. 3 day holds are pretty common, since any NSF sort of return is supposed to happen in that time frame.

dkarapetyan 12y ago

So they use FTP and files as an RPC mechanism. What happens when you accidentally overwrite files? How does sequencing happen? Do they use timestamps on the files? It sorta, kinda makes sense and I can't really deny the simplicity of the whole scheme.

edawerd 12y ago
I'm sure every bank has their own protocol, but ours requires us to datestamp and incrementally sequence our filenames.
wiredfool 12y ago
Generally, there's a confirmation step for transaction counts and file totals. Also, there's something of a convention to never send the same file name twice.

martin_ 12y ago

Seems very logical, not much to learn in part 1! Does the ACH still hit the federal reserve if the two accounts are at the same bank?

wiredfool 12y ago
Maybe, depends on the bank. It certainly doesn't have to if the bank is optimally processing the file.
- BallinBige 12y ago
  there is a lot of discussions and actions being made for intra-day settlements.
  - logicalmind 12y ago
    Yep, here are the current details: https://www.nacha.org/news/nacha-leads-industry-toward-ubiquitous-same-day-ach-settlement https://www.nacha.org/news/nacha-leads-industry-toward-ubiqu...
    - BallinBige 12y ago
      IMO - this is the only way ACH can remain competitive with Card transactions. Intra-day settlements and returns
      - wiredfool 12y ago
        Speeding up returns will be a nice bonus, though there's still a long window for fraudulent returns that can really bite.
      - logicalmind 12y ago
        The whole payment space is getting really interesting in the last couple of years. Banks and retailers trying to work around credit card processing fees as they became larger part of their balance sheets.

SkyMarshal 12y ago

Good start. Would love to see what an actual ACH file looks like. Googling returns some specs and the like, but not sure if any contain the exact doc that gets FTP'd to the Fed.

logicalmind 12y ago
If you google for an example "nacha file" instead of an "ach file" you should be able to find what you're looking for. Here is one example of what one looks like: http://www.treasurysoftware.com/ach.html http://www.treasurysoftware.com/ach.html

logicalmind 12y ago

If you want to get into the nitty gritty of the format of ACH/NACHA files you can buy the spec here: https://www.nacha.org/nacha-estore-rules https://www.nacha.org/nacha-estore-rules But you can find parts of the book online at various places. Many financial institutions support NACHA files, but you'll also find many that violate the spec. I happen to have implemented a C# NACHA implementation recently and it wasn't a lot of fun. And there is a huge difference between ACH receipt and ACH origination.

jarrett 12y ago

So, an entity that's set up with an ODFI can initiate arbitrary debits to arbitrary accounts, with no action by the owner of the debited account. What happens if that privilege is abused? Is it like chargebacks with credit cards? What if the debit is so small the victim doesn't notice?

logicalmind 12y ago
There is a strict system in place for violating the rules: https://www.nacha.org/NSfines https://www.nacha.org/NSfines But if things occur on accident, there is a "Returns" process for handling it. It looks like the author intends to cover that, at least partially, in the next installment. Here is a list of return codes if you want a hint: http://www.mainstreetmerchantsolutions.com/ach-return-codes http://www.mainstreetmerchantsolutions.com/ach-return-codes
notdonspaulding 12y ago
There are all sorts of policy-based resolution methods in the ACH world. But there is nothing technologically restricting arbitrary debits/credits to arbitrary accounts in arbitrary amounts. One policy meant to deal with this is called "Velocity limits" which is basically a rate-limit of how much the OFDI will underwrite your account for. i.e. You can debit up to $50,000/day and then your OFDI will cut off further ACH transactions until some of your outstanding ones have settled. Another policy is that (for Check21 checks processed via ACH anyway) the checking account owner has up to 60 days from the statement date to dispute the charge, meaning the ACH transaction can be reversed up to 90 days after it was initiated. It's straight out of the 60's. And on one hand, it's cool that everybody uses this system and nobody notices how old it is. On the other hand, it's freaky when you realize that every time you swipe a debit card or write a check, you've basically handed over all the credentials needed for that person to debit your account as much as they like (until they're discovered). Also, remember that automatic deposit implies automatic withdrawal. ACH systems are by far the craziest API integrations I've ever had to do.

chicagomint 12y ago

"documentation explaining the ACH system is targeted towards bankers, not software developers." The ACH system itself is designed for the benefit of bankers, not developers, or even depositors. Bitcoin alleviates the need for the excesses of the described system.

dedward 12y ago
Bitcoin doesn't let me withdraw US $ from one US bank account and deposit it in another US bank account in bulk. Bitcoin lets me transfer bitcoin around - which is fantastic and wonderful - but it doesn't address the problem at hand.
- scotty321 12y ago
  You don't understand. Once you're in the Bitcoin ecosystem, you don't necessarily need to backtrack out into US $ anymore. I buy almost everything with Bitcoin, and shop at Bitcoin-friendly stores. Except for grocery stores. I don't know of any grocery stores yet that accept Bitcoin in my area, but they will surely arrive someday.

deleted 12y ago

[deleted]

weishigoname 12y ago

seems logical

clintcparker 12y ago

I've integrated with several domestic ACH APIs, and none of them are FTP based. Most are SOAP services.

mikesickler 12y ago

Is there no getting around debiting party A into your own account, then crediting party B from your own account? Is it not possible to initiate a direct payment from A to B?

jordanbaucke 12y ago

Obligatory "Bitcoin will disrupt this" post.

hafichuk 12y ago
Not in our lifetime. Cryptocurrencies will just be another bolt on and thing we need to integrate. The upshot is that the banks probably won't manage this. The downside is that the banks probably won't manage this.

vinhboy 12y ago

I hope you guys continue with this series and make the next one more in-depth. I am very curious how everything work, especially the fees.

edoceo 12y ago

I too was in finance. Had to write ACH processing for loan payments and collection. No fun. However, there are plenty of docs from the Fed. No test systems tho :(. I think I'll go look for some of my old ACH code just for fun.

perlpimp 12y ago

"moves electronically through the banking system today" I assume only in United States? I wonder if one can automate SWIFT transfers the way one does ACH, that would be epic.

scotty321 12y ago

THIS is why Bitcoin. THIS.

ipince 12y ago

What are the fees? Random question: is this how Dwolla does its transactions--through ACH?

BlueStar 12y ago

I'm an ACH product manager who's worked the user side of ACH for years, and I've never seen a conversation like this. It's amazing. Even though most of it went off on a file-transfer tangent, I've picked up some really interesting tips. Like, I never imagined there would be stuff about ACH on GitHub. BTW, ZenPayroll is an amazing product and I want to work there.