Interface Transaction Standards: Technical Specifications
Disclaimer: RDSP issuers
The information contained on this page is technical in nature and is intended for Registered Disability Savings Plan (RDSP), Canada Disability Savings Grant (grant) and Canada Disability Savings Bond (bond) issuers. For general information, visit the RDSP section.
Consult this page frequently for newer versions. The following laws and regulations take precedence over information contained in InfoCapsules in the event of discrepancies:
- Income Tax Act
- Canada Disability Savings Act
- Canada Disability Savings Regulations
5.0 Technical Specifications
This section of the ITS document describes the data interface for the exchange of information between the CDSP system and issuers/authorized agents. These technical specifications are intended for use in support of system development to implement data interchanges with the CDSP system.
This document is the standard by which information is exchanged with the issuer/authorized agent for the application and administration of the grant and/or bond. Data integrity rules are described in detail in this document. Descriptions of the business and general rules under which data is processed within the CDSP system are described in the foreword of this document.
Operational aspects of the movement of data and functions used to manage the movement of data files are not part of this document but are found in the Data Operations and Connectivity Guide. Operational functionality includes the following:
- logging of files
- authentication of authorized agent
- transmission verification
- transmission mechanisms
Detailed operational instructions concerning reporting schedules and methods of transfer of information may be obtained by using the contact information below or by accessing the Service Partner page on the ESDC website.
- Electronic Services Section
- 140 Promenade du Portage, Mailstop: Bag 4
- Phase IV, Gatineau, Quebec
- K1A 0J9
- Telephone : 1-888-276-3632
- E-mail : email@example.com
5.2 CDSP System Transaction Processing Record Format Overview
These technical specifications describe a data interface that is based on the exchange of bulk data files. Authorized agents are required to conform to the record formats and rules specified herein as well as other data interchange rules described in the Data Operations and Connectivity Guide.
This portion of the ITS outlines both input and output data record formats. Input records are used to record contract registration information, record beneficiary and holder information and report financial transactions. Output records report the status of reported data in the form of transaction processing files and error files on a record-by-record basis.
5.3 Logical Record Types
Source transactions are identified by a record type code as outlined in the following table:
|001||Header Record (Source of transaction)|
|002||Sub-header Record (Used only when the CDSP system reports back to authorized agent in processing report)|
|003||Files Processed (Used only when the CDSP system reports back to authorized agent in processing report)|
|101||Contract Registration Information|
|102||Contract Update Transactions|
|201||Update Beneficiary and Holder or Add/Remove Holder|
|202||Add/Update and Revoke Consent Transactions|
|801||Transaction Errors in Error File|
|851||Severe errors in Error File|
|901||Successfully processed transaction in Transaction Processing File|
|921||SIN Usability information in SIN Usability File|
|951||Contract Status in Contract Status File|
|952||Episodic DTC Elections in Contract Status File|
|953||SDSP Elections in Contract Status File|
|971||Transferred information in Transfer Extract File|
|981||DTC Eligibility in Beneficiary DTC Eligibility File|
|999||Trailer Record (Control Count)|
5.4 File/Record Structure
- All transaction files have a header record containing standard identification details.
- All files have a trailer record containing a count of the number of records in the file including the header and trailer records.
- Files contain a mix of transactions, identified by a numeric record type code. This has been set at three (3) digits to allow for possible future expansion.
- Source input files contain fixed length records, with record types being padded as necessary to meet a consistent standard. This enables different record types to be included in the same file.
5.5 Data Formats
- The ISO-8859-1 Latin 1 Character Set is the official Treasury Board of Canada, Information Technology Standard (TBITS) for data interchange. All data is provided in ISO-8859-1 format (numeric values are stored in their character representation) as shown in Appendix B.
- All fields are fixed length and occupy fixed positions within a record.
- Character data is left justified and padded with trailing spaces except for BN.
NOTE: BN cannot be padded with spaces. If a record type "001" contains a space character (ASCII value 32) the file is rejected, and if any other record contains a space in the authorized agent BN field the record is rejected.
- Numeric data is right justified with leading zeroes.
- Most amount fields are standardized at 9 digits (10 bytes) with two explicit decimal places (i.e. up to a maximum of $9,999,999.99); negative amounts contain a minus sign "-" as the first character in the field.
NOTE: The amount field in record type "002" is longer than other amount fields allowing a maximum value of $9,999,999,999.99 (13 bytes).
- List-type data fields use code tables whenever practical (e.g. Province codes and Error codes).
- Record types 101, 102, 201, 202, 401, 501, 701 and 971 include a transaction type code. Separate codes are used with each type of transaction in order to identify the specific processing requirements.
5.6 Record Separators
Records within files must be separated by a record separator character(s). Record separator characters vary depending on the originator's operating system. The CDSP system replaces the carriage return (CR, decimal value 13) record separator character with the UNIX new line character (NL, decimal value 10).
Only the new line and carriage return characters are acceptable as record separators. No other record separator characters may be used.
5.7 End of File
The CDSP system rejects files that do not conform to the following rules:
- Files must have a type "999" record as the last record.
- The type "999" must have a record separator character following it.
If the end of file (EOF) character is provided, the following rules apply:
- The CDSP system accepts any single character as an EOF character following the type "999" record.
- No characters may follow the EOF character.
5.8 File Naming Standards
The physical naming of files is described as follows:
- To CDSP system : "CDSP " + File type + Authorized Agent BN + Transactions Latest Month + Date Sent + File number
- From CDSP system : "CDSP" + File type + Authorized Agent BN + Date Processed + CDSP system File number + extension
If the filename is not 36 characters long, and/or not formatted as outlined, an error record type 8001 is generated.
The combination of BN, Transactions Latest Month, Date Sent, and File number must be unique. If the same combination has already been received and processed by the CDSP system, the file is rejected and an error record type 8002 is generated.
If the Transactions Latest Month is in the future, the file is rejected and an error record type 8013 is generated.
The following definitions apply to the components of the file-naming standard:
|Program Identifier||The Program Identifier must be CDSP|
|File type||One uppercase character indicates the file type. The file type character indicates whether the file is a production file, a summary reporting file, a test file or a test summary reporting file.
|Authorized Agent BN||15 character Business Number|
|Transactions Latest Month||6 numeric character date YYYYMM|
|The latest month to which the transaction dates in the file relate|
|Date Sent||8 numeric character date YYYYMMDD|
|File number||2 digit file number|
|Must be between 01 and 99|
|Generated by CDSP system for .pro, .err, .sur, .reg and .xfr files.|
|Extension||The file extension is one of:
5.9 File Type
Production files being submitted to the CDSP system must begin with "CDSPP" while files starting with "CDSPT" are used strictly for industry testing and are never parts of a production file group. The procedures for industry testing are outlined in the CDSP System Industry Testing Guide.
5.9.1 File number
There may be instances where an authorized agent wishes to send more than one file in a single day. In order to be able to give each file a unique name, the file name contains a file number. If the authorized agent sends one file in a day, a file number must be provided, though it can be any two-digit value. The ordering of the file numbers will not be enforced. The file number is used purely to distinguish files sent on the same day.
5.9.2 File Extension
Files returned to the authorized agent have the same file type and BN but have the CDSP system processing date and file number in the prefix. In each reporting period a .pro , .err , .reg (if applicable), .xfr (if applicable) and .dtc file is returned to the authorized agent. The SIN Usability File, a .sur file, is returned to the authorized agent following the monthly production run. The following is an example of a filename group:
- Input Files
- Output Files
- CDSPP123456789RC00011998121501. err
- CDSPP123456789RC00011998121501. reg
- CDSPP123456789RC00011998121501. pro
- CDSPP123456789RC00011998121501. sur
- CDSPP123456789RC00012009121501. xfr
- CDSPP123456789RC00012009121501. dtc
All file names are in uppercase except file extensions.
5.9.3 Header and Trailer Record
The header record (adhering to the File Identification Standard) is the first record in the file and the trailer record, providing a control count of the records in the file, is the last.
The trailer record sent by the CDSP system contains:
- the unique file number assigned by the CDSP system and
- the date CDSP system processing occurred.
5.10 Source Data Definition Standard
Transaction format and content is defined in this document using a common ( COBOL ) standard, with the following symbols for data attributes:
|X||Any printable alphanumeric character (includes numbers, letters, punctuation marks, spaces and other special characters). The entire field contains spaces if not used. For example : the letter A in a 3 character alphanumeric field is stored as "A ". The number 5 in a character alphanumeric field is stored as "5 ".|
Any number. The entire field contains zeros if unused (blanks are not allowed). If larger than 1 digit, the contents are right justified with leading zeroes. For example : the number 5 in a 3 character numeric field is stored as "005".
Note: Negative amounts are preceded by a minus sign "–" as the first character in the field.
|( )||Indicates a recurrence of the preceding data type, with the number of occurrences stored inside of the parenthesis. For example : 9(6) means a number up to six digits long, X(6) means 6 consecutive characters of alphanumeric data.|
5.11 Standard Data Formats
The following table outlines standard formatting rules for common data field types:
|Dates||X(8)||Valid date formatted YYYYMMDD.|
|Up to maximum of $999,999,999.99. Decimals are explicit i.e. a contribution of $1000.00 is reported as 000001000.00 with the appropriate number of leading zeros for padding the field to the correct length (000001000.00).
|Filler||X(n-500)||Unused field. Must contain the specified number of spaces, or optional comments and is ignored regardless of its contents.|
All record types follow a standard layout, with the same fields occurring in the same positions to the extent possible.
5.12 Transaction Sequence
The CDSP system will process transactions in a logical order. Issuers should be aware of this and as much as possible all transactions should be submitted in a logical sequence.
All contract elements, including beneficiary, holder and PCG (where the beneficiary is under the age of 18) must be established in the CDSP system before financial transactions can be processed.
Contract registration information and the respective financial transactions pertaining to the contract can be sent in the same file. However, the processing of the financials remains dependent on the successful establishment of the contract elements.
Report a problem or mistake on this page
- Date modified: