> 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.
To say it's secure is a stretch, so say it's completely unsecure is also inaccurate. There were multiple improvements I recommended to the service, but I think I only got 1 or 2 approved. Lets just say this, the front door is secure, but the once you're inside, its not so great. It's not incompetency, its just we (the security guys) are always fighting an uphill battle against change.
Also, I could tell you worst stories about other services all the banks use that would make anyone cringe worst than this, some simple cross bank privilege escalation, oh yeah and the developers said thats not really going to happen... I resigned within a month of that.
As the client, though - we uploaded via SFTP, the connections were IP restricted and the files were PGP encrypted.
I know that doesn't address what happens after we send the bank the file - but that's not our concern, right?
Other story: I've add access to a FTP server which also served as a way to submit JCL at an escalated privilege to an IBM server!
Mostly "enterprise" security is a joke; it depends on the people not the technology.
Yes, I know the difference between FTP and SFTP. In this case the technical details are important: SFTP is effectively a bolt-on file transfer protocol which requires an already established (authenticated) connection. It is most easily used with SSH, but as far as I recall, it could be implemented to work from any protocol that has the concept of a session. (And if my memory serves me right, SILC implemented it as a logical replacement for DCC.)
The other security measures you list also make me feel better. From other posters I have already learned that NACHA transfers have an integrity check file which may be, in some systems, ignored. If the files are indeed PGP encrypted, then that may be less of an issue. The message integrity checks in PGP are certainly robust. :) [Corruption-in-transit becomes a moot point, and the same applies for route hijacking.]
I give you wholehearted thanks, and want to offer an apology for my earlier tone. However, I still have a reason to cringe.
Just let me cringe at the article author instead.
There's also FTPS, which is FTP with TLS. That's closer to "secure FTP," but as @segmondy pointed out, this isn't what they use.
When I read it I thought the author was claiming plain FTP was secure too.
From wikipedia (http://en.wikipedia.org/wiki/File_Transfer_Protocol#Secure_F...)
"The SSH file transfer protocol or secure FTP (SFTP)..."
Multiple google searches also yielded similar language.
I was pleasantly surprised. This conversation implied that 777ing it was a considered choice, as opposed to having just happened because YOLO. This puts them much higher up the healthcare IT totem pole than you would hope.
When I was involved with this it was SFTP for the transfer, to a write-only folder (you couldn't list contents) and the file uploaded had to be PGP encrypted with a key the bank gave us and we verified over the phone before starting the process.
Even if it had been email, or plain FTP, the file was encrypted and only the bank had the key... even we couldn't decrypt it, due to the nature of Public Key encryption.
Plain old FTP is not considered secure by any means, and is largely disappearing - SFTP is standard now.
Thank $deity for that.
As well it should. But it gets worse. Much, much worse:
It often amazes me that the U.S. financial system works at all.
> ...I eventually reached the conclusion that "check clearing" doesn't mean anything at all. What there really is, is a web of trust among large financial institutions. They take actions which work 99% of the time, and then they have correction procedures for the 1% that fail...
> ...their primary concern is that I'm not a con man who is going to take money out of the system. As long as the cash is EITHER at their bank, OR at the original bank, they can afford to not be completely sure just where it is, and to work that accounting out over time.
> This system is totally unlike how computer scientists would design it. They would want guarantees that the money really was only in one place, and there would be a thing which is a "transaction", where the money reliably went from one place to another. A wire transfer is something like that, but it's really bootstrapped on old-time banking, which is a trust relationship with repair procedures, not a guarantee of freedom from error.
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.
That's true, but there was a lot of additional evidence that they really didn't know:
1. They said they didn't know.
2. Two weeks passed during which they could not find the money.
3. The money was only found after the person in whose account it ended up contact me (not the bank!)
And, BTW, I actually found out later how the mistake had been made: the original wire form had been filled out wrong. It was supposed to be a for-benefit-of wire, but the form was filled out as if for an intermediate-institution wire. And the bank employee who entered the data was apparently completely clueless because they entered an account number as an ABA number (or maybe it was the other way around, it was a long time ago). But it was without a doubt a total clusterfuck from beginning to end.
> barring a very small percentage they all work
Yes. As I said, this never ceases to amaze me.
Secure-ftp is not the only security measure used in transmitting ACH files. There other measures too - including but not limited to: Checking source IP in a stateful way, Out of band confirmation by email/fax/phone, hardcoded limits and out-of-pattern detection mechanisms. I won't mentioned the specifics of some of these since this is a public forum but defrauding the ACH system by hacking into sftp is neither trivial nor scalable.
Again no system is full proof but ACH fraud is typically 1/3rd of the fraud in Credit Card networks and has been the same percentage for decades.
The author probably had it this way because they did want to spend the money for a 3rd party integrator which would process the transaction via a web service.
Hey I can't believe EDI is still alive but it is....
I think maybe OP is essentially a third party integrator?
What does this mean?
Slightly more easily recognizable version might be "the shoemaker's children have no shoes".
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.
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.
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.
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.
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.
None of the payment processing providers differentiate between the two.
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.
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:
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 .
Anyone have other resources they've found useful/informative?
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
Are there any libraries to create the ACH file itself from basic information like ODFI, etc?
What's that, you want line endings?
I've seen \r, \n, and \r+\n. Nothing like 96 characters in a 94 character format.
I assume only in United States? I wonder if one can automate SWIFT transfers the way one does ACH, that would be epic.
It sorta, kinda makes sense and I can't really deny the simplicity of the whole scheme.
Also, there's something of a convention to never send the same file name twice.
Is it not possible to initiate a direct payment from A to B?
Random question: is this how Dwolla does its transactions--through ACH?
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.
Bitcoin lets me transfer bitcoin around - which is fantastic and wonderful - but it doesn't address the problem at hand.