Interface transaction standards - Canada Disability Savings Program system

Comments and questions regarding this document may be addressed to

Employment and Social Development Canada –ESDC
Electronic Services Section
Phase IV, Mailstop: Bag 4
140 Promenade du Portage
Gatineau QC  K1A 0J9
Telephone: 1-888-276-3632
Email: rdsp-reei@hrsdc-rhdcc.gc.ca

In this section

• 1.1 Foreword

1.1 Foreword

The CDSP system Interface Transaction Standards (ITS) document outlines the procedures for formatting and submitting transactions electronically to the CDSP system. This foreword provides additional information about the requirements in the ITS and explains how the CDSP system, developed in support of the RDSP, CDSG and CDSB, validates and processes the transactions reported by the RDSP issuer.

The words "authorized agent" are used throughout this document to mean the organization conveying information electronically to the CDSP system and receiving CDSG and CDSB payments from the CDSP system. This organization must be the issuer of the RDSP as approved by the CRA, or an agent for the RDSP issuer. There may only be one agent and one issuer per RDSP specimen plan. However, the CDSP system does not consider a service provider who purely facilitates the electronic transfer of information to be the sending organization or authorized agent on behalf of the RDSP issuer.

The term "contract" is used throughout this document to mean a registered disability savings plan approved by the CRA.

When reference is made to the "RDSP issuer", this is the organization ultimately responsible for the administration of the RDSP, CDSG and CDSB and, specifically, the organization that has secured approval for the particular RDSP specimen plan from the CRA. This organization has been authorized to offer its services to the public as an issuer, has been identified as the issuer for a particular specimen plan, and has signed an agreement with ESDC allowing the issuer to administer the CDSG and CDSB.

Although the CDSP system validates certain information that it receives electronically prior to making CDSG and CDSB payments, RDSP issuers are reminded that all amounts of CDSG and CDSB are paid on the condition that the RDSP complies with all relevant legislative requirements. This includes the RDSP registration rules described in Section 146.4 of the Income Tax Act and the conditions relating to the RDSP found in the Canada Disability Savings Act and its related regulations. All amounts of CDSG and CDSB are subject to repayment to the Crown should ESDC or the CRA later discover payment was made inappropriately.

2.1 File format overview

Authorized agents can submit one or more files for processing in any reporting period. The file name is structured to allow several files to be reported on a given day or for a given period. In addition to the authorized agent BN and the file date, a file number is added for further distinction. The file number need not be in any specific order. It exists solely to make multiple file names unique for files sent on the same day.

The file itself must conform to a specific structure. A file must consist of a header record (record type 001) followed by the transaction(s) formatted as specified below in this document, with a trailer record (record type 999) at the end. Failure to follow this structure will result in rejection of the file.

Any files the CDSP system receives from an authorized agent after the data delivery cut-off date will be held and processed in the next reporting period, unless otherwise notified. The authorized agent is responsible for ensuring that files arrive in a timely manner to be processed within a particular processing period.

2.2 Record format overview

Once all certification requirements are met, it is necessary for the authorized agent to inform the CDSP system of all relevant activity concerning the RDSP. All activity must be reported to the CDSP system electronically as follows:

• contract registration information, which is used to establish the contract, beneficiary and holder information for purposes of registration
• information updates and changes relating to the non-financial aspects of the RDSP, such as beneficiary and holder information (personal), contract information and consent information
• financial transactions such as contributions, requests for grant or bond, retirement savings rollover and reversal, education savings rollover and reversal, grant/bond repayment and reversal, disability assistance payment (DAP), lifetime disability assistance payment (LDAP) and their reversals and contribution corrections
• election transactions, which report occurrences of Specified Disability Savings Plan (SDSP) elections
• reporting transactions, which are utilized to report fair market value (FMV), and contract transfer information

Transactions submitted to the CDSP system are categorised by record type and transaction type. Contract registration information is reported using a record type 101, while changed or updated information to previously registered contracts is reported using a record type 102 (contract) or 201 (beneficiary and holder). Information adding or revoking consent for residency, DTC eligibility and income validations at the CRA is reported utilizing record type 202. All financial transactions fall into record type 401. Record type 501 is utilized for SDSP elections. A record type 701 includes all reporting transactions. Within each record type there are one or more transaction types.

When the CDSP system receives a file for processing, the format and content of each transaction is validated (see each record type as described in this document for layout format and validation rules). If transactions are not submitted within the guidelines outlined, the transactions may be rejected and the authorized agent will be responsible for performing the necessary corrections and resubmitting the data. The authorized agent will receive confirmation of acceptance in the processing files that the CDSP system sends back to the authorized agent. If any transaction is rejected, it will appear in the error file identifying the nature of the error.

2.3 Transaction reporting sequence

Transactions must be submitted in a logical sequence. A contract must achieve a status of registered via the submission of contract registration information before any update or change transactions (RT 201 - beneficiary and holder update information) can be processed. As well, the CDSP system must have received contract registration information before any financial transactions (RT 401 - financial transactions) can be processed. While transactions may be in any order in the submission file, the CDSP system will process all transactions in the following order: contract registration information (RT 101 and RT 102), update/change information (RT 201), consent information (RT 202), elections (RT 501), financial (RT 401) and reporting information (RT 701).

2.4 Timeliness of transaction processing

In Budget 2012, the requirements that new contracts are reported within 60 days, that contributions and bond requests are reported within 180 days and that transfers be completed within 120 days, were removed. These were replaced with a requirement that the issuer act without delay in reporting these transactions.

2.5 Reporting period cut-off date

The CDSP system will process files and pay CDSG and/or CDSB on a monthly basis. Schedules with processing dates (transaction periods, file submission cut-off and CDSG and/or CDSB payment dates) will be sent out to the authorized agent via ListServ (an electronic notice) on a periodic basis. Reporting periods extend from the first day of the month to the last day of the same month. Authorized agents are given 4 business days after the reporting period ends to finalize their file(s) to be sent for processing. Authorized agents are not to include any transactions that occurred after the last day of the reporting period.

2.6 Transaction formats

There are several transaction formats that will be used to report information to the CDSP system. These formats are outlined in detail in the Transactions format section of this document. The CDSP system implementation date for each defined transaction is listed in the Transactions format section as well.

3.1 Contract registration transactions

3.2 Contract update transactions

3.3 Beneficiary and holder update transactions

3.4 Consent transactions

With the introduction of the carry forward measures in Budget 2010, RDSPs may now attract CDSG and/or CDSB for the current year plus the 10 previous years. Entitlements may be paid dating back to the later of the implementation of the RDSP in 2008 and the beneficiary's year of birth.

The holder and PCG information provided within the contract, holder and financial transactions is used in order to determine DTC eligibility, Canadian residency and family income for the beneficiary. Authorized agents may request that the personal information of additional PCGs be used for the same purpose by submitting consent transactions.

3.5 Financial transactions

To ensure the proper payment of the CDSG and CDSB, authorized agents must report to the CDSP system all financial transactions for a beneficiary utilizing record type 401. Financial transactions include all movements of funds in and out of an RDSP, but not the growth or investment activities (these amounts are to be reported using record type 701 - reporting information). The CDSP system will determine eligibility and the amount of CDSG and/or CDSB payment using the information provided in the request transactions. Payments of CDSG and/or CDSB will only be made to contracts that have achieved a registered status. The following transactions can be submitted:

• contributions and/or request for grant
• contributions and/or request for grant corrections
• retirement savings rollovers
• retirement savings rollover reversals
• bond requests
• grant and/or bond repayments including termination adjustments
• grant and/or bond repayment reversals
• LDAP
• DAP
• LDAP reversals
• DAP reversals
• education savings rollovers
• education savings rollover reversals

3.6 Election transactions

3.7 Reporting transactions

At the beginning of each month, authorized agents are required to report various growth and investment activities by contract to the CDSP system. These activities are conveyed using record type 701 - reporting information. The following transactions must be submitted:

• monthly reporting of FMV
• reporting of FMV and earnings when transferring a contract

4.1 Error file

This ITS details the format that is required for each transaction type, and provides the authorized agent with the validation rules for those transaction types. If transactions are not submitted in compliance with these format and validation requirements, the transactions are subject to rejection. Each transaction error, whether due to problems in format or invalid data, is reported back to the issuer or authorized agent for correction and resubmission. This is done electronically via the transaction error file.

These transaction errors include:

• failure to correctly format the file
• failure to correctly format a transaction
• failure to supply the necessary information for a mandatory field
• failure to comply with CDSP system business rules

The error file contains 2 different record types, RT 801 - Errors and RT 851 - Severe errors. A list of error codes can be found appended to this document (Appendix A).

4.2 Transaction processing file

At the end of each processing period, the CDSP system returns a transaction processing file to the authorized agent. The processing file provides the details of results for all successfully processed transactions submitted (such as how much CDSG and/or CDSB money was paid in respect of each contribution or bond request, or how much CDSG and/or CDSB money was repaid). Every transaction submitted to the CDSP system and successfully processed will appear in this file including those financial transactions which have been processed without CDSG or CDSB being paid. A refusal reason will accompany each of the aforementioned transactions which have not received CDSG or CDSB. A list of refusal reasons can be found appended to this document (Appendix A).

The file is the CDSP system's confirmation to the authorized agent that the submitted transactions were correctly formatted, contained all the mandatory information and passed all the necessary validation rules. The processing file will also list all contract, beneficiary and holder information transactions that were successfully processed.

CDSG and/or CDSB transactions which have been re-adjudicated (either positively or negatively) are also reported to the authorized agent in the transaction processing file. The CDSP system performs re-adjudication on financial transactions under the following situations:

• contract registration - authorized agent resubmission of contract information after the processing of unpaid grant and/or bond requests
• contribution correction - authorized agent submitted financial transaction releasing grant for previously submitted contributions
• retirement savings rollover reversal - authorized agent submitted financial transaction releasing grant for previously submitted contributions
• education savings rollover reversal - authorized agent submitted financial transaction releasing grant for the previously submitted contributions
• contract closure (transfer completed) - authorized agent transferring out closes contract allowing for the re-adjudication of pending grant/bond for authorized agent transferring in
• CRA reassessment or update of DTC, residency, income and/or contract status

The transaction origin field (transaction position 68-69 in the RT 901.pro file) documents the above circumstances allowing for the differentiation of CDSP system-generated transaction records and authorized agent transaction results records.

The processing of an authorized agent's file(s) results in a series of CDSG and/or CDSB payments and repayments. Repayments are netted out from the payments. This generally results in a payment to the authorized agent. The payment will be automatically deposited into the authorized agent's account according to the banking information supplied to the CDSP system.

The record type 901 - Transaction processing file carries with it an indication of the effect the transaction has on the payment received by the authorized agent. The payment requisitioned flag tells the authorized agent if the 901 record is a payment or repayment of CDSG or CDSB, to or from the CDSP system. For example, the processing of a contribution transaction would result in the payment of CDSG to the authorized agent (assuming it passed all the rules and no refusal reason was present). The payment requisitioned flag would be set in this case. In the case of a DAP or LDAP there is no money moving between the authorized agent and the CDSP system. The payment requisitioned flag would not be set for those transactions. The authorized agent can reconcile all flagged transactions with the payment received from the CDSP system.

4.3 Contract status file

Each month the CDSP system will process all contract registration information transactions and report back the current status of the contract transaction to the financial institution. In certain circumstances the CDSP system will receive information from the CRA that affects the contract registration status of a particular contract. Any change in the contract status (current and/or at contract signature date) will be reported back to the authorized agent with the record type 951 in the contract status file. If there is more than 1 change, only the most up to date status will be indicated. The 'reason for change of contract status' field was added to this report in version 2.0 of the ITS in order to clarify why a contract status has been changed. The 'transfer status' field was added to this record type in version 2.1 of the ITS in order to convey the current status of a contract being transferred. Beginning with version 3.1 of the ITS, the purpose of the contract status file is expanded to inform the financial institution of the successful processing of new or updated SDSP elections.

4.4 SIN usability file

Each month the CDSP system will verify the integrity of all beneficiary and holder SINs through the Social Insurance Registry (SIR). As a result of this monthly verification, any particular SIN may either be identified (flagged) by SIR as not usable or identified (un-flagged) by SIR as usable. The CDSP system will report the information regarding the usability status of SINs back to issuers/authorized agents via the record type 921 - SIN usability file (.sur).

4.5 Transfer information extract file

Beginning in January 2013, ESDC will provide to the receiving issuer, all historical transactional information in ESDC's possession from all previous contracts for a particular beneficiary for all RDSP transfer transactions when following criteria is met:

• a valid close contract transaction must be received from the originating/relinquishing issuer
• the contract transfer from the relinquishing to the receiving issuer must be resolved, and
• the new contract under the receiving issuer must be registered

The record type 971 - Transfer information extract file (.xfr) will include all information from all prior issuers that can be used by the receiving issuer for the ongoing administration of a particular beneficiary's RDSP.

The transactions of the .xfr file are as follows:

• 971-01 - Contribution/Contribution correction information
• 971-02 - Bond request information
• 971-03 - Retirement savings rollover/Retirement savings rollover reversal information
• 971-04 - Grant/Bond repayment - Grant/Bond repayment reversal information
• 971-05 - DAP/DAP reversal information
• 971-06 - LDAP/LDAP reversal information
• 971-07 - Education savings rollover/Education savings rollover reversal information

The details of each individual transaction type for the RT-971 - Transfer information extract file (.xfr) are outlined in Section 11 of this document.

4.6 Beneficiary DTC eligibility file

Beginning in February 2015, the CDSP system will extract and send authorized agents all updated beneficiary DTC eligibility information via a record type 981 - Beneficiary DTC eligibility file (.dtc). This monthly generated file will report all updates which have been made by the CRA to the yearly DTC eligibility status of beneficiaries who have a pending (having passed Social Insurance Registry (SIR) validation) or registered contract. In transfer situations, this information will be sent to the latest relinquishing issuer if the transfer is unresolved or to the receiving issuer upon resolution of the transfer and registration of the contract.

The record type 981 - Beneficiary DTC eligibility file will also include an annual DTC eligibility status update produced in February of every calendar year providing an update of all beneficiary DTC eligibility profiles for that calendar year.

The initial file scheduled to be sent during the February 2015 processing period will report the DTC eligibility profiles of all beneficiaries by year, beginning from the year of the contract signature date to the year the file is produced. It will not provide information for carry forward years or for contracts that have a status other than pending (passed SIR validation) or registered.

5.1 Scope

This document is the standard by which information is exchanged with the issuer/authorized agent for the application and administration of the CDSG and/or CDSB. 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.

Employment and Social Development Canada
Electronic Services section
Phase IV, Mailstop Bag 4
140 Promenade du Portage
Gatineau QC  K1A 0J9
Telephone: 1‑888‑276‑3632
Email: rdsp-reei@hrsdc-rhdcc.gc.ca

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:

5.4 File/record structure

All transaction files have a header record containing standard identification details and 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 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 business number. A 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 0.

Most amount fields are standardized at 9 digits (10 bytes) with 2 explicit decimal places (up to a maximum of $9,999,999.99); negative amounts contain a minus sign "-" as the first character in the field. 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 (such as 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) (CR, decimal value 13) record separator character with the UNIX new line (NL) character (NL, decimal value 10).

Only the newline 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 record type 999 as the last record
• the record 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 record type 999
• no characters may follow the EOF character

5.8 File naming standards

The physical naming of files is described as follows:

• to the CDSP system: "CDSP" + file type + authorized agent BN + transactions latest month + date sent + file number
• from the 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:

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 part of a production file group. The procedures for industry testing are outlined in the CDSP System Industry Testing Guide.

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:

5.11 Standard data formats

The following table outlines standard formatting rules for common data field types:

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.

6.1 Record type 001 – Header record

Purpose: To identify the source of a transaction file.

Requirements: None.

6.2 Record type 002 – Sub-header record (transaction processing file)

The record type 002 is only included in the transaction processing file produced by the CDSP system.

Purpose: The sub-header records supply reporting period information, 1 for each issuer in the transaction processing file.

Requirements: This record is generated by the CDSP system and occurs as the second record type in the transaction processing file.

6.3 Record type 003 – Files processed record (transaction processing file)

The record type 003 is only included in the transaction processing file produced by the CDSP system.

Purpose: The files processed record gives the name of a production file sent by the authorized agent that was processed by the CDSP system during the production run. 1 record is generated for each production file sent and processed.

Requirements: This record is generated by the CDSP system and occurs as the third record type in the transaction processing file.

6.4 Record type 101 - Contract registration information

Record type 101 is used to provide all contract information relating to registration.

Purpose: Issuers use this record type to provide all information elements necessary to register a new contract.

Requirements: The record type 101 requires 3 separate components to achieve registration of a contract. These include:

• record type 101, transaction type 01, contract information
• record type 101, transaction type 02, beneficiary information
• record type 101, transaction type 03, holder information (report 1 transaction type 03 for each holder named on the contract)

All components of a contract registration information record must be submitted during the same production cycle, and all must have the same issuer transaction number. The CDSP system will process all components as 1, and return the results to the authorized agent, identifying errors on each component, if applicable. A single error on any 1 component will "error out" all 3 components. All 3 components must be resubmitted in 1 processing cycle when correcting an error.

6.4.2 The 101-02 transaction - Record component layout - Contract registration - Beneficiary information

6.4.3 The 101-03 transaction - Record component layout - Contract registration - Holder information

6.5 Record type 102 - Contract update information

Record type 102 is used by the issuer to update contract information. There are 2 contract update transaction types reported, 10 - Close a contract and 11 - Rename a contract.

Purpose: Issuers use these record types to perform specific updates to a contract.

Requirements: The record type 102 will refer to the contract number requiring updates.

6.6 Record type 201 - Beneficiary and holder update information

Record type 201 is used to update beneficiary information, update holder information, as well as adding and removing a holder from a contract. These transactions are only to be used in situations where the contract has already achieved a status of registered.

Purpose: Issuers use these record types to change the contract information elements that have been previously reported on a registered contract registration information transaction with respect to the beneficiary and or the holder.

Requirements: The record type 201 refers to the beneficiary or holder where the information held in the CDSP system needs to be changed.

6.7 Record type 202 - Consent information for beneficiary

Record type 202 is used to add or revoke consent for the beneficiary as well as to update said consent.

Purpose: Issuers use these record types to add, revoke or change consent information required by the CRA with respect to the beneficiary.

Requirements: The record type "202" will refer to the beneficiary where add, revoke or update consent information is required.

6.8 Record type 401 - Financial transactions

Record type 401 is used by the issuer to report all financial transactions and to request CDSB payments. There are 14 financial transactions types reported, as follows:

• 01 – contribution/grant request
• 02 – contribution/grant request correction
• 05 – request for bond payment
• 06 – stop bond payment
• 08 – retirement savings rollover
• 09 – retirement savings rollover reversal
• 10 – repayment of grant and/or bond
• 11 – reverse repayment of grant and/or bond
• 20 –DAP
• 21 –LDAP
• 22 – DAP reversal
• 23 – LDAP reversal
• 30 – education savings rollover
• 31 – education savings rollover reversal

Purpose: Issuers use these record types to report all financial transactions that occur on a registered contract.

Requirements: The record type 401 will refer to the contract number of the contract and the date on which the financial transaction occurs with the issuer.