In theory, C lines can be mixed with D lines in the same file. If a D line has fewer than 6 segments, it is padded to 1464 characters.Ī C line has the same layout. If we do the math, 24 + 6×240 = 1464 characters. Each transaction in a D line is called a "segment". After that, a transaction is described in 240 characters. taking funds from the client's bank account.Ī D line has a 24-character header (not to be confused with the file header, or A record). In our example, the D line contains a single debit transaction, i.e. Note that not every text editor is capable of displaying long lines.Ī PAD file has a header and a trailer, denoted by A and Z respectively. You may save and open it in a text editor. The first letter of each line indicates the type of transaction. The reason it's called a 1464-byte format is that each line contains 1464 characters. A PAD file is just a text file with padded fields. However this is enforcement by regulation, not by standards.
Of course they will never charge their clients an amount that's not agreed upon. Essentially, the submitter of a PAD file, or the "originator", can write themselves cheques of arbitrary amounts. It is a physical file that is generated, can be edited at will, and then upload via an authenticated online banking interface. It turns out that CPA 005 has none of that. One thing that all the documentation is missing, is that how is a CPA 005 file, "run"? If CPA 005 is anything like a modern web standard such as JSON, XML, shouldn't it also define its interface? Is it REST or SOAP? How is the transmission authenticated? OAuth or other security tokens? As for participating banks who receive PAD files, shouldn't they provide endpoints (web locations) of their services? The Execution Context, or the "Interface" That void cheque you provide to your utility company or loan provider contains the very information that's needed to encode a PAD file. Nowadays, the PAD files are still used to batch pre-authorized transactions. For example RBC has processing centres in Vancouver, Calgary, Regina, Winnipeg, Toronto, Montreal and Halifax, according to documentation.
Regional "processing centres" were designated to receive the tapes. Not any bank branch could process the tape. This was the period when one bank had to fully trust the other bank. Most of the settlement time was spent on the physical transportation of the tape. Enough time, usually in a matter of days, was set aside for the transactions to settle. Thousands of transactions were recorded on tape. Historically, CPA 005 was intended for batched, inter-bank transactions. We hope that this article removes the uncertainties and unnecessary guesswork for anyone who wishes to implement the CPA 005 standard.
We took the painstaking process of cross-referencing the specifications from all available sources and reverse engineering known working files, and finally came up with the resource you are reading now. As far as programming is concerned, none of the existing CPA005 documentation is complete. Although they are useful to decipher the information a CPA005 (or PAD) file contains, combining all the documentation is still not sufficient to generate a PAD file from scratch. Unfortunately, all these documents are riddled with omissions, inconsistencies and blatant errors.
CIBC EFT 80 BYTE FILE LAYOUT DEFINITIONS SOFTWARE
Other banks and software vendors also briefly mention the CPA 005 format. The Royal Bank of Canada (RBC) also lists out the various formats they use, specifically the CPA005 Debit and CPA005 Credit file layouts. The latest official documentation can be found here. The Canadian Payments Association has published the standards for the CPA 005 1464-byte file format, or "CPA 005" for short.
0 kommentar(er)
