Canada Disability Savings Program System - Industry testing guide

Outlines the guidelines and processes for industry testing of the Canada Disability Savings Program (CDSP) system.

Disclaimer: RDSP issuers

The information contained on this page is technical in nature and is intended for Registered Disability Savings Plan (RDSP) issuers. For general information, visit the RDSP section.

On this page

Alternate formats

Canada Disability Savings Program System – Industry testing guide [PDF - 366.1 KB]

Large print, braille, MP3 (audio), e-text and DAISY formats are available on demand by ordering online or calling 1 800 O-Canada (1-800-622-6232). If you use a teletypewriter (TTY), call 1-800-926-9105.

List of acronyms

BN
Business number
CDSB
Canada Disability Savings Bond
CDSG
Canada Disability Savings Grant
CDSP
Canada Disability Savings Program
CESP
Canada Education Savings Program
CRA
Canada Revenue Agency
DAP
Disability assistance payment
ESDC
Employment and Social Development Canada
ID
Identification
ITG
Industry testing guide
ITS
Interface transaction standards
LDAP
Lifetime disability assistance payment
MSFT
Managed secure file transfer
PCG
Primary Caregiver
RDSP
Registered Disability Savings Plan
RT
Record type
SIN
Social insurance number
SIR
Social insurance registry

List of tables

Versions

Version number: 3.3

Version date: August 2026

Document version history

Version: 1.0

  • Date: September 3, 2008
  • Description: Initial version

Version: 1.0

  • Date: October 6, 2008
  • Description: Final version

Version: 1.1

  • Date: February 27, 2009
  • Description: Added requirements for ITS version 1.2 in Annex A, replaced term ViaSafe with MSFT and updated mailing address.

Version: 1.2

  • Date: July 20, 2009
  • Description: Modified Annex A to remove age requirements.

Version: 2.0

  • Date: November 23, 2009
  • Description: Added ITS version 2.0 requirements in Annex A.

Version: 2.1

  • Date: February 1, 2010
  • Description: Added ITS version 2.1 requirements.

Version: 2.1

  • Date: September 20, 2010
  • Description: Added ITS version 2.1 transfer requirements.

Version: 2.2

  • Date: December 30, 2010
  • Description: Added ITS version 2.2 requirements.

Version: 2.3

  • Date: August 31, 2011
  • Description: Added ITS version 2.3 requirements.

Version: 3.1

  • Date: March 31, 2013
  • Description: Added ITS version 3.1 requirements.

Version: 3.1

  • Date: September 6, 2013
  • Description: Updated department name and other minor changes.

Version: 3.1

  • Date: March 1, 2020
  • Description: Removed Episodic DTC election transactions and Episodic DTC election reversal transactions from Annex A.

Version: 3.3

  • Date: July 2026
  • Description: Updated due to renewal of industry testing process and WEB compliance.

Key terms and definitions

Agent

An organization to which the responsibilities as outlined in the Issuer Agreement have been conferred to. ESDC requires a letter from the issuer identifying who will act as their agent, as well as a letter from the agent accepting responsibility for the duties as outlined in the letter from the issuer.

Authorized agent

The organization sending information electronically to the CDSP system and receiving grant and bond payments from the CESP. This organization must be the issuer of the RDSP as approved by the CRA or an administrative agent for the RDSP issuer.

Issuer

The organization responsible for the administration of the RDSP, the CDSG and the CDSB and, specifically, the organization that has secured approval for the RDSP specimen plan from CRA.

Production run

Term used to describe the processing of the industry transactions by the CDSP system.

Protected

Safeguard of particularly sensitive information with high risk of injury to individuals as well as certain public or private interests. This information is marked "protected" and is kept in secure areas.

Service provider

The organization assigned by the agent to provide support services for the administration of RDSPs.

1.0 Introduction

The CDSP system ITG outlines the guidelines and procedures required to successfully complete industry testing of the CDSP system. It should be read in conjunction with the current version of the CDSP system ITS.

1.1 Purpose

The goal of industry testing is to ensure that issuers can provide quality data in the files they are submitting to the CESP for processing by minimizing the number of errored and rejected transactions. In addition, the industry testing process helps financial institutions ensure that their system is ready to report transactions to, and receive transactions from, the CDSP system.

1.2 Scope

This document is limited to the industry testing process and includes criteria for satisfying the related requirements.

1.3 Schedule

Authorized agents can schedule a testing timeframe with the E-Services team at any time. Once a test file has been transferred to the CESP, an email should be sent to the industry testing mailbox at EDSC.CN.PCEE.TESTDEINDUSTRIE-INDUSTRYTESTING.CESP.NC.ESDC@esdc-edsc.gc.ca as outlined in the file submission section of the industry testing process.

1.4 Confidentiality

Test files provided by authorized agents may contain live data such as SIN information and/or financial information and is considered "protected". The data volume information and client specific information is considered competitive information and is treated with confidentiality, as are the test results. Specific information about an issuer, agent or service provider will not be disclosed to any other issuer, agent, or service provider.

All test files must be transferred to the CESP using the secure method specified in the file submission section of the industry testing process. Test files submitted in violation of this security requirement will not be tested under any circumstances.

2.0 Industry testing process

Authorized agents are required to create test data and send data files to the CESP for testing. The data is then processed by the E-Services team and, upon completion, the test results are sent back to the authorized agent for review.

2.1 File creation

The authorized agent is responsible for creating and sending a file or set of files to the CESP for testing. Service providers must submit separate files for each agent they represent. Filenames should be prefixed with "CDSPT".

Refer to the appendices section for information pertaining to the types and volumes of transactions required for each test.

Note: The method used for creating transactions in industry testing must be the same method used in production.

2.2 File submission

MSFT is the ESDC approved internet connectivity solution software for transmitting files electronically. Files can be sent for industry testing upon successful completion of connectivity testing.

Test files sent through MSFT are not automatically queued up for testing. An email must be sent to the industry testing mailbox at EDSC.CN.PCEE.TESTDEINDUSTRIE-INDUSTRYTESTING.CESP.NC.ESDC@esdc-edsc.gc.ca once the test files have successfully been transferred to the CESP. The email should contain the following information:

  • name of issuer, agent, and service provider if applicable
  • filename(s) submitted for testing
  • name and contact information of individual(s) responsible for submitting data and retrieving results
  • specify if live data is included in test files (specimen plan and business numbers provided by CRA must be used for industry testing)
  • CDSP release number or ITS version used for testing
  • special processing instructions (for example, special test cases such as a simulation of multiple production runs)

2.3 File processing

Each industry test is processed against a non-populated database. The reason for this is to give the agent complete control over the data environment used for testing and to facilitate the interpretation of the results. The agent is responsible for preparing the test environment by submitting a file containing baseline data such as contracts, beneficiaries, and holders to the CDSP system. Subsequent files should be submitted, and will be processed, in the order specified in the appendices section.

The SIR and CRA validation processes are simulated in the test environment and all validation rules are automatically passed.

2.4 Transaction processing results

Transaction volumes and success rates are reported back to the agent in the Production processing results report upon completion of processing the test file(s). Cumulative volumes and success rates will be provided in situations where multiple files were sent and processed in the same cycle.

2.5 CDSP system output files

At the completion of each simulated production run, the following output files will be generated (if applicable) and reported back to the agent:

  • an error file (.err)
  • a transaction processing file (.pro)
  • a contract status file (.reg) (if applicable)
  • a transfer information extract file (.xfr) (if applicable)
  • a beneficiary DTC eligibility file (.dtc) (if applicable)

Note: Refer to the current version of the CDSP system ITS for a description of the format of the output files.

Once received, the CDSP system output files should be loaded into the authorized agent's system to update the processed transactions and record the CDSG and CDSB amounts in their system.

3.0 Industry testing success criteria

The Production processing results report generated by the CDSP system provides the success rate of industry testing files submitted by authorized agents. The report provides volume and quality success rates by transaction type. The minimum requirements needed to successfully complete industry testing are detailed in the appendices section. Testing the education savings rollover transaction and the retirement savings rollover transaction is not mandatory unless the issuer plans on implementing the rollover functionality in their system.

Only CRA approved specimen plans (those used in the production data files) will be accepted during industry testing. Transactions that are processed against non-approved specimen plans will be rejected.

3.1 Circumstances requiring industry testing

Industry testing is required under the following business and system related circumstances:

  • a new RDSP issuer
  • the implementation of the education savings rollover functionality
  • the implementation of the retirement savings rollover functionality
  • the addition of an authorized agent
  • a change of service provider
  • a specimen plan transfer
  • a system update or conversion

Industry testing may also be required for certain business or system related circumstances other than those listed above. The issuer is responsible for contacting the CESP Enrolment team at NC-INSCRIPTION_ENROLMENT-GD@esdc-edsc.gc.ca who in turn will coordinate with the CESP E-Services team. Once informed of the circumstances, the CESP E-Services team will inform issuers of which tests must be conducted.

A repeat of industry testing will be required when submitted transactions are repeatedly generating unacceptable error rates in the production environment. In situations where unacceptable error rates are on-going, the issuer and/or agent may be suspended from sending production files to the CDSP system until such a time as lower error rates are established in industry testing.

3.2 Volume criteria

Transaction volume requirements for the various industry tests are detailed in the appendices section.

3.3 Success rates

Minimum success rate requirements for the various types of industry tests are defined in the appendices section. Success rates are calculated based on the ratio of the number of successfully processed transactions (error is not generated) to the number of processed transactions by transaction type.

4.0 Appendices

This section outlines the transaction type and transaction volume requirements and the minimum success rate requirements for the various types of industry tests.

4.1 Appendix A: Full test

Appendix A outlines the details of the CDSP transactions required for a full industry testing cycle.

Note: Each file must be successfully tested before proceeding to the next file until all requirements in each file are met.

4.1.1 File 1 test requirements-Contract registration transactions

All components of a contract registration package (101-01, 101-02, 101-03) must be submitted in the same test file and each of the three components must have the same issuer transaction number. The contracts submitted in file 1 must receive a registered status prior to the submission of file 2.

Table 1: File 1 test requirements-Contract registration transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
101 01 Contract information (PCG information omitted) 95% 90% 25
101 02 Beneficiary information 95% 90% 25
101 03 Holder information 95% 90% 25
101 01 Contract information (with PGG SIN information) 95% 90% 25
101 02 Beneficiary information 95% 90% 25
101 03 Holder information 95% 90% 25
101 01 Contract information (with agency BN information) 95% 90% 25
101 02 Beneficiary information 95% 90% 25
101 03 Holder information 95% 90% 25

4.1.2 File 2 test requirements-Contract transfer scenarios, SDSP elections, and rename contract, update beneficiary, add holder, update holder, and add/update consent transactions

A new contract registration package (101-01, 101-02, 101-03) must be reported for the 'new' contract in a transfer scenario. The 101-01 contract transaction must have the transfer indicatory set to 'Y' (Yes) and the values for 'other specimen plan' and 'other contract' must match existing values in the test database.

Table 2: File 2 test requirements-Contract transfer scenarios, SDSP elections, and rename contract, update beneficiary, add holder, update holder, and add/update consent transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
101 01 Contract information (PCG information omitted/transfer = Y) 95% 90% 5
101 02 Beneficiary information 95% 90% 5
101 03 Holder information 95% 90% 5
101 01 Contract information (with PGG SIN information/transfer = Y) 95% 90% 5
101 02 Beneficiary information 95% 90% 5
101 03 Holder information 95% 90% 5
101 01 Contract information (with agency BN information/transfer = Y) 95% 90% 5
101 02 Beneficiary information 95% 90% 5
101 03 Holder information 95% 90% 5
102 11 Rename contract 95% 90% 5
201 02 Update beneficiary 95% 90% 5
201 03 Update holder 95% 90% 5
201 13 Add holder 95% 90% 5
202 01 Add/update consent 95% 90% 5
501 03 SDSP election 95% 90% 5

4.1.3 File 3 test requirements-Financial transactions / contribution and/or grant request and bond request

PCG information is specified only until the end of the month in which the beneficiary turns 18.

Table 3: File 3 test requirements-Financial transactions / contribution and/or grant request and bond request
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 01 Contribution / grant requested = 'N' 95% 90% 15
401 01 Contribution / grant requested = 'Y' (omit PCG information) 95% 90% 15
401 01 Contribution / grant requested = 'Y' (with PCG SIN information) 95% 90% 15
401 01 Contribution / grant requested = 'Y' (with agency BN information) 95% 90% 15
401 05 Bond request (omit PCG information) 95% 90% 15
401 05 Bond request (with PCG SIN information) 95% 90% 15
401 05 Bond request (with agency BN information) 95% 90% 15

4.1.4 File 4 test requirements-Contribution and/or grant request correction, stop bond request, remove holder, and revoke consent transactions

Contribution correction transactions allow the issuer to correct a contribution amount, correct PCG information or modify the grant requested flag for a previously submitted contribution.

Table 4: File 4 test requirements-Contribution and/or grant request correction, stop bond request, remove holder, and revoke consent transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 02 Contribution correction Requirement: Correct contribution amount 95% 90% 5
401 02 Contribution correction Requirement: Correct PCG information 95% 90% 5
401 02 Contribution correction Requirement: grant requested = 'Y' where previously = 'N' 95% 90% 5
401 06 Stop bond (omit PCG information) 95% 90% 5
401 06 Stop bond (with PCG SIN information) 95% 90% 5
401 06 Stop bond (with agency BN information) 95% 90% 5
201 23 Remove holder 95% 90% 5
202 02 Revoke consent 95% 90% 5

4.1.5 File 5 test requirements-DAP, LDAP, repayment, and contract closure transactions

The repayment transaction can be used to report a repayment or a termination adjustment or both.

Table 5: File 5 test requirements-DAP, LDAP, repayment and contract closure transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
102 10 Close contract 95% 90% 5
401 10 Repayment Reason = 01 DAP 95% 90% 1
401 10 Repayment Reason = 02 LDAP 95% 90% 1
401 10 Repayment Reason = 03 Contract termination 95% 90% 1
401 10 Repayment Reason = 04 Contract ceases to be registered 95% 90% 1
401 10 Repayment Reason = 05 Beneficiary ceases to be DTC eligible 95% 90% 1
401 10 Repayment Reason = 06 Death of beneficiary 95% 90% 1
401 10 Repayment Reason = 07 Non entitlement (as per legislation) 95% 90% 1
401 10 Repayment Reason = 08 Bond payment rectification 95% 90% 1
401 20 DAP 95% 90% 5
401 21 LDAP 95% 90% 5

4.1.6 File 6 test requirements-Reversal transactions and reporting transactions

Original transactions must be successfully processed before sending the corresponding reversal transaction.

Table 6: File 6 test requirements-Reversal transactions and reporting transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 11 Repayment reversal 95% 90% 5
401 22 DAP reversal 95% 90% 5
401 23 LDAP reversal 95% 90% 5
501 04 SDSP election reversal 95% 90% 5
701 01 Monthly reporting of FMV 95% 90% 5
701 02 Transfer reporting of FMV and earnings amounts 95% 90% 5

4.2 Appendix B: Transfer and correction test

Transfer and correction testing may be required under the following circumstances:

  • a transfer by plan amendment
  • a merger or amalgamation

4.2.1 File 1A and File 1B-Baseline data

The relinquishing (originating) issuer must first submit two files with baseline data.

Table 7: File 1A-Baseline data
Record type Transaction type Description Volume of transactions
101 01 Contract information (old specimen plan ID) 25
101 02 Beneficiary information (old specimen plan ID) 25
101 03 Holder information (old specimen plan ID) 25
401 01 Contribution / grant request 10
401 05 Bond request (old specimen plan ID) 10
Table 8: File 1B-Baseline data
Record type Transaction type Description Volume of transactions
503 01 SDSP election (old specimen plan ID) 10

4.2.2 File 2A and File 2B test requirements-Transactions from the receiving issuer

These files will contain the transactions under the new specimen plan ID that are required to be submitted by the receiving issuer. The 101-01 contract registration transaction should have the transfer indicatory set to 'Y' (Yes) and the values for 'other specimen plan' and 'other contract' must match existing values in the test database - meaning values that were successfully processed in File 1. All active SDSPs under the relinquishing plan must be resubmitted under the receiving plan using the 501-03 transaction.

Table 9: File 2A test requirements-Transactions from the receiving issuer
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
101 01 Contract information (new specimen plan ID) 100% 100% 25
101 02 Beneficiary information (new specimen plan ID) 100% 100% 25
101 03 Holder information (new specimen plan ID) 100% 100% 25
401 05 Bond request (new specimen plan ID) 100% 100% 10
Table 10: File 2B test requirements-Transactions from the receiving issuer
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
501 03 SDSP election (new specimen plan ID) 100% 100% 10

4.2.3 File 3 test requirements-Transactions from the relinquishing issuer

The third test file will contain data from the relinquishing (originating) issuer including the old specimen plan ID.

Table 11: File 3 test requirements-Transactions from the relinquishing issuer
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
102 10 Close contract (old specimen ID) 100% 100% 25
701 02 Transfer Reporting of FMV and Earnings Amounts 100% 100% 25

4.2.4 File 4 test requirements-Contribution correction transactions

A correction test should be conducted following the transfer test. The goal is to verify that the new system can correct data from the old system. The file will contain data from the receiving (new) issuer including the new specimen plan ID.

Table 12: File 4 test requirements-Contribution correction transactions
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 02 Correction of contribution previously sent by the relinquishing promoter (new specimen plan ID) 100% 100% 10

4.3 Appendix C: Retirement savings rollover test

Appendix C outlines the requirements for the Retirement savings rollover transaction industry testing cycle. The test is broken up into 3 separate files and detailed in the following sections.

Note: Each file must be successfully tested before proceeding to the next until all the requirements in each file are met.

4.3.1 File 1-Baseline data

Issuers must first submit a file with baseline data to establish contracts and beneficiaries in the test environment. It is not necessary to submit File 1 with baseline data if this test is performed at the same time as the Full test cycle.

Table 13: File 1-Baseline data
Record type Transaction type Description Volume of transactions
101 01 Contract information 15
101 02 Beneficiary information 15
101 03 Holder information 15

4.3.2 File 2 test requirements-Retirement savings rollover transaction

The Retirement savings rollover transaction (401-08) will be sent in File 2.

Table 14: File 2 test requirements-Retirement savings rollover transaction
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 08 Retirement savings rollover 95% 90% 15

4.3.3 File 3 test requirements-Retirement savings rollover reversal transaction

The Retirement savings rollover reversal transaction (401-09) will be sent in File 3.

Table 15: File 3 test requirements-Retirement savings rollover reversal transaction
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 09 Retirement savings rollover reversal 95% 90% 15

4.4 Appendix D: Education savings rollover test

Appendix D outlines the requirements for the Education savings rollover transaction industry testing cycle. The test is broken up into 3 separate files and detailed in the following sections.

Note: Each file must be successfully tested before proceeding to the next until all the requirements in each file are met.

4.4.1 File 1-Baseline data

Issuers must first submit a file with baseline data to establish contracts and beneficiaries in the test environment. It is not necessary to submit File 1 with baseline data if this test is performed at the same time as the Full test cycle.

Table 16: File 1-Baseline data
Record type Transaction type Description Volume of transactions
101 01 Contract information 15
101 02 Beneficiary information 15
101 03 Holder information 15

4.4.2 File 2 test requirements-Education savings rollover transaction

The Education savings rollover transaction (401-30) will be sent in File 2.

Table 17: File 2 test requirements-Education savings rollover transaction
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 30 Education savings rollover 95% 90% 15

4.4.3 File 3 test requirements-Education savings rollover reversal transaction

The Education savings rollover reversal transaction (401-31) will be sent in File 3.

Table 18: File 3 test requirements-Education savings rollover reversal transaction
Record type Transaction type Description Data format success rate Overall success rate Volume of transactions
401 31 Education savings rollover reversal 95% 90% 15

Page details

2026-08-06