CPA-005 file format: the Standard 005 EFT file

What EFT Rails does

You send each payment through EFT Rails without building a bank file. Payments are created and read through the API or in the dashboard, so your integration supplies payment instructions instead of producing records at fixed character positions.

The API checks bank account details against the fields carried by the file: a three-digit institution number, a five-digit branch or transit number, and an account number of up to twelve digits. Each payment also carries a bank reference you can quote and your own reference, which is returned unchanged.

The API reference documents the payment and account fields your integration sends.

What the standard covers

The standard defines the payment files exchanged between banks, including their character set, record lengths and order. Standard 005 is read with Payments Canada's F rules, and the receiving bank retains the prerogative to edit a file.¹ CPA in the name stands for the Canadian Payments Association, the corporation the Canadian Payments Act establishes.²

Files exchanged between banks use the Extended Binary Coded Decimal Interchange Code character set, abbreviated EBCDIC.³ Record types A, C, D, E, F, I, J and Z are 1,464 characters long, while S, U and V records are 208 characters long.⁴

A payment file opens with an A record and closes with a Z record.⁵ C, D, E, F, I and J records can be mixed within one file.⁶ The credit and debit records carry the payment data, while the other records handle corrections and returns.

Transaction type codes and return reason codes are defined in Standard 007.⁷

How a record is built

A record identifies itself, carries a count and then holds payment data in fixed positions. All records begin with their type letter and record count. Apart from the A and Z control records, a record contains one or more transactions, with one transaction per segment. All segments in a record have the same length and layout.⁸

Unused segments contain spaces throughout. Once a blank segment appears, all later segments in that record must also be blank.⁸

Within a used segment, an unused numeric field contains zeros and an unused alphanumeric field contains spaces. Numeric fields are right-justified and zero-filled. Alphanumeric fields need no particular justification, but they must be space-filled and can contain hyphens.⁹

The A record

The A record identifies and controls the file. It is the file header, occurs once at the start, and any invalid field in it causes the file to be rejected.¹⁰

The file creation number occupies four positions in the header. Dates use six digits in the form 0yyddd: a zero, the last two digits of the year and the day number within the year. A file can be rejected when its creation date is more than seven calendar days before the bank runs its initial edit.¹¹

The currency code is CAD for Canadian-dollar transactions or USD for US-dollar transactions. Any other value causes rejection.¹²

The C and D records

The C record carries credits, described as deposit data, and the D record carries pre-authorized debit (PAD) data. In both records, positions 1 to 24 contain the type letter, record count and origination control data. A 240-character segment follows, repeated up to six times, with segments two to six occupying positions 265 to 1464.¹³

Segment one of a D record has this layout:

The institution identification field has nine digits: a leading zero, the three-digit institution number and the five-digit branch number. The number must appear on Payments Canada's financial institutions file, or the payment is rejected.¹⁴

An amount must be greater than zero, or the payment is rejected. An invalid amount can also put the file out of balance, which can cause the entire file to be rejected.¹⁵

A debit's Due Date is the date on which it should be charged to the payor's account. A debit dated more than two business days after the file is exchanged can be rejected.¹⁶

The Z record

The Z record closes the file and supplies the totals used to check its contents. It is the last record and begins with the type letter, record count and origination control data. Its control totals occupy positions 25 to 112, followed by filler through position 1464.¹⁷

Corrections and returns

An E record lets the originator reverse a C credit, while an F record lets the originator reverse a D debit. An I record returns credit data, and a J record returns debit data.¹⁸

The reason supplied with a return uses a return reason code from Standard 007. The EFT return codes guide explains those codes and the reconciliation work they trigger.

What gets a file rejected

A rejected file fails the receiving bank's edit before its payments proceed. Rejection can result from an unreadable file, a missing A or Z record, an out-of-balance file, an invalid field, an impermissible mixture of record types, or a file coming from a bank in default. The receiving bank can stop at the first fault it finds.¹⁹

A file-level rejection differs from a return matched to an individual payment. The reject versus return guide explains how to identify which outcome you received and what to correct.

Your bank's specification

Your bank's specification tells you how to prepare and transmit a file through its channel. Banks publish client layout documents using the standard's positions, and those documents can restrict a file to one payment type, impose narrower date windows or add transmission records around the file.

That document governs the channel to your bank. Standard 005 governs the payment file inside it. When diagnosing a refusal, compare the record and position with the standard first, then check the additional requirements in your bank's specification.