For those criticizing the author for 'fantasy' security problems, it seems relevant to emphasize that they work at a bank---their threat model is probably rather more vigorous than most.
> they work at a bank---their threat model is probably rather more vigorous than most Until one day when you work with ACH files and start having existential dread about the american payroll system.
The file format is archaic, but not objectively worse than any alternative (modern or contemporary). It helps to think of an ACH file as an expression of a line protocol, with field framing and offsets and some internal checksumming.
ACH files are mostly human-readable in their raw form (some simple vim highlighting goes a long way), and that was surely a design goal. It is terse (important for 1960's era data transfer/storage costs) which makes it information-dense, which remains a feature today.
As a system, the ACH Network is incredibly reliable and secure. The security is built into the system, not into the file format. Only trusted players are invited to participate, and the threat of removal is much greater than any enticement to deceive. Furthermore, it is a full-recourse system. Errors can be backed out after the fact.
File delivery is secured in the usual way. Preshared keys, SSH/SSL, etc. ACH is more secure than your bank/broker website, or any ecommerce transactions.
I would like to see encrypted (or at least cryptographically-signed) ACH files, and I wish ACH was used in support of something quicker than a 2x/day (business days only) batch settlement cycle...but that's an interbank/Fed issue.