What is the CPA 005 EFT file format?

CPA 005 is a plain-text file format used to send a batch of payments — payroll, vendor payments, refunds, or pre-authorized debits — to a Canadian financial institution for processing in a single upload. Instead of keying each payment into online banking one at a time, you build one file that contains every transaction and hand it to your bank.

Every major Canadian bank accepts the format, and most of them expect it once a payment run grows past a handful of transactions. It is the everyday plumbing behind Canadian direct deposit and pre-authorized debit.

CPA 005 is published by Payments Canada — the body that operates Canada’s core payment systems, formerly named the Canadian Payments Association (the “CPA” the format is named after). The full title of the standard is Standard 005, “Standards for the Exchange of Financial Data on AFT Files.” AFT stands for Automated Funds Transfer: the system that moves direct deposits and pre-authorized debits between Canadian banks.

Payments Canada defines the format; individual banks implement it. Because the standard is shared, a correctly built CPA 005 file is portable across institutions — but each bank layers its own field edits, originator ID rules, submission channel, and cut-off times on top of the standard. That is why a file one bank accepts can still be rejected by another. The standard tells you what a valid file looks like in general; your bank’s own file guide tells you what they additionally require.

A CPA 005 file is built from fixed-length records, each exactly 1464 characters long. That length is why the format is also marketed as “1464” or “1464-byte” — it is the same standard, not a separate one. “CPA 005,” “1464,” and “EFT file” are three names you will see for this format; some banks brand their offering one way, some another.

Every file uses four record types:

• A — file header. One per file. Carries the originator ID, the file creation date, and the file creation number.
• C — credit detail. Carries deposits — money going out to a recipient, such as payroll or vendor payments.
• D — debit detail. Carries collections — money pulled in from a payer, such as a pre-authorized debit.
• Z — file trailer. One per file. Carries the control totals the bank uses to confirm nothing was added or lost in transit.

There are also four return/error record types — E, F, I, and J — but those appear in files the bank sends back to you, not in files you originate.

Detail records (C and D) consist of a short record header followed by transaction segments, and each record is padded with spaces or zeros out to the full 1464-character length. The exact field positions inside each record are defined precisely by the standard and by each bank’s own specification — and lining all of those up by hand is the hard part. The rest of this page is about why.

Not every Canadian bank uses CPA 005. A few — TD is the most common example — accept or require an older, shorter format known as the 80-byte EFT layout.

The two are not the same standard. The 80-byte layout is a separate fixed-length format with an 80-character record instead of 1464, and it carries fewer fields per transaction. It predates the wide adoption of CPA 005 and survives mainly because some bank platforms never migrated off it.

This is where the term “EFT file” gets confusing: on its own it is ambiguous — it can mean either format. The only reliable way to know which one you need is to check your bank’s published file specification or ask their cash-management team. A simple rule of thumb: if you see “1464” in your bank’s documentation, that is CPA 005; if you see “80-byte” or “EFT80,” that is the older layout. A file built to one will be rejected by a bank expecting the other — the record lengths alone don’t match, so the bank’s parser fails on the very first line.

PayFile Pro generates both. For the 80-byte layout, see the TD page. For the banks that use CPA 005, read on.

CPA 005 is accepted by every major Canadian financial institution. The differences are in the details — each bank applies its own field edits, originator ID format, submission channel, and cut-off times. PayFile Pro maintains a per-bank page for the institutions where those differences matter most:

• RBC — CPA 005 credit and debit files for Royal Bank business clients.
• BMO — CPA 005 for BMO business clients; BMO brands its layout “1464.”
• CIBC — CPA 005 for CIBC’s batch payment channels.
• Scotiabank — Scotiabank brands its layout “CPA005 1464.”
• ATB Financial — CPA 005 for ATB business accounts.
• Credit unions — most Canadian credit unions clear AFT through Central 1, which publishes a CPA 005-based specification with its own edits.

Each page covers that institution’s specific requirements and links to the matching generator.

A CPA 005 file either clears the bank’s edit check or it doesn’t — and a rejection usually means re-cutting the entire file. The standard names specific, recurring failure causes. The ones that catch businesses most often:

• File Creation Number not incremented. The File Creation Number is a sequence value (0001–9999) in the A record. It must increase with every production file you send. Submit a duplicate, or a number lower than your last file, and the bank rejects it as a suspected re-send.
• Record length not exactly 1464. Every line must be exactly 1464 characters. A short line — usually a record that wasn’t padded out, or trailing spaces stripped by a text editor — fails the parser on the first read.
• Date funds to be available outside the allowed window. The standard limits how far ahead of, or behind, the file creation date the due date can sit. A back-dated or far-future date pushes a transaction outside that window and it rejects.
• Invalid originator ID, institution number, or transit number. These are validated against the bank’s records. A typo, a wrong-length field, or an unrecognized ID rejects the affected transaction — or the whole file, if the error is in the header’s originator ID.
• Control totals that don’t reconcile. The Z trailer carries record counts and dollar totals that must match the detail records exactly. If they don’t, the bank can’t trust the file and rejects it.
• Debits and credits mixed when the bank wants them separate. The standard allows C and D records in one file, but many banks require separate files or separate batches for collections and deposits. Mixing them against a bank that doesn’t allow it is a rejection.
• Wrong character encoding or line endings. CPA 005 is fixed-width plain text. Exporting from a spreadsheet or word processor can introduce the wrong encoding, hidden characters, or inconsistent line endings — all of which break a fixed-width parser.

None of these are visible until the bank runs its edit check. That feedback loop — build, upload, wait, get rejected, fix, re-cut — is the single biggest reason businesses reach for a dedicated tool instead of building the file by hand.

There are three common ways to produce one:

• Accounting or ERP software. If your accounting package has a Canadian EFT module, it can usually export a CPA 005 file directly. This works well if you already own the software and it supports your bank.
• Your bank’s portal. Some banks let you enter payments one at a time in online banking with no file required — fine for a few payments, slow and error-prone for a full payroll or vendor run.
• A dedicated file generator. PayFile Pro builds a bank-ready CPA 005 file in your browser: enter or import your payments, choose your bank, and download a file built to that bank’s specification — no accounting software, no manual record-building, and no waiting on an IT request.

PayFile Pro lets you preview the output before you commit, so you can confirm the file is correct before you sign up. Pick your bank to start: RBC · BMO · CIBC · Scotiabank · ATB · Credit unions.