It's Not Just NACHA: How 'ACH' Works Differently Around the World
In the last post we opened up a NACHA file, the batch format behind US payroll, rent, and subscriptions. But NACHA is a US only standard. So what happens when a company has employees or vendors in Canada too? It turns out every country has its own version of "the everyday batch payment," and they don't automatically talk to each other.
Same idea, different paperwork
Think of it like driving across a border. The idea of "a car" is universal, but the paperwork, the license plate format, the rules of the road, even which side you drive on, can be completely different once you cross the line. Payment batches work the same way.
Canada's version: EFT, or "CPA 005"
Real world example: a US company with a Canadian office needs to pay its Toronto based employees every two weeks, the same way it pays its US employees. It can't just reuse its NACHA file, Canada has its own format, commonly called EFT (Electronic Funds Transfer), built to a standard known as CPA 005.
The idea is the same as NACHA, bundle a bunch of payments into one file and hand it to the bank, but the details are different:
| NACHA (US) | CPA 005 / EFT (Canada) | |
|---|---|---|
| Who oversees it | The ACH network operators | Payments Canada |
| How accounts are identified | A 9 digit routing number | An institution number plus a branch transit number |
| Record length | 94 characters per line | 1,464 characters per line |
| Basic structure | File Header, Batch Header, Entries, Batch Control, File Control | A record (header), C records (each payment), Z record (trailer) |
| Everyday example | Payroll, rent, subscriptions | Same idea, payroll, rent, bill payments, just north of the border |
So the concept, "batch a bunch of payments and settle them overnight," is identical. But the file itself is built differently enough that a bank's system needs to know which country it's dealing with before it can even read the file correctly, like knowing whether to read a label in miles or kilometers.
Where ISO 20022 comes back in
This is exactly the kind of problem ISO 20022 was built to solve. Instead of a company's accounting software needing to know how to build both a NACHA file and a CPA 005 file, it can send one standard pain.001 instruction, "pay these people this amount on this date," and let the bank figure out the local format on the back end.
This is also where having a bank with real operations in both countries matters. J.P. Morgan is a good example, its treasury services business processes both US ACH and Canadian EFT payments for companies that operate on both sides of the border, plus a network of Canadian processing sites (Vancouver, Calgary, Winnipeg, Montreal, and Halifax) to handle the receivables side too. From the company's point of view, they're not thinking about NACHA versus CPA 005 at all, they're just telling their bank who to pay, and the bank handles which local rulebook applies.
Why this matters if you're building payment software
If you're building software that touches payments, the lesson here isn't "memorize every country's file format." It's that a payment system needs to treat "how do I move this money locally" as a separate problem from "what did the customer ask for." That's precisely the gap ISO 20022 is closing, one instruction format, translated locally by whichever bank or network actually moves the money.
What's next
We've now covered wires, US ACH, and Canada's EFT. Next up: real time payments, the newer rails (like FedNow and RTP in the US, and similar systems elsewhere) built to give everyday payments the same instant speed as a wire, without the wire price tag.
Further reading: