Chapter 3. Registered Education Savings Plan provider user guide – The Canada Education Savings Program system and Interface Transaction Standards

3.1.3.1. Managed secure file transfer

RESP promoters must use managed secure file transfer (MSFT) software to send data to the CESP system via the Internet. ESDC recognizes it as a secure method of data encryption and is Entrust enabled.

3.1.3.2. Schedule of cut‑off dates for production runs

ESDC provides schedules identifying applicable processing dates, which include:

• processing periods
• production run cut‑off dates
• payment dates

These schedules are forwarded to RESP promoters as an electronic bulletin. They are also available on the Resources for RESP promoters web page under the Systems documentation tab.

3.1.3.3. Reporting and processing periods

Each calendar month corresponds to a specific reporting period in which promoters:

• generate new RESP transactions as they occur, and
• correct transactions that were either rejected or not submitted accurately to the CESP system in previous periods

Each processing period begins after the last day of the corresponding reporting period, on the first day of the following month. The CESP system processes promoter files that are submitted by 5 pm, Eastern Time, on the fourth business day of each month. These files cannot include any transactions that occurred after the last day of the corresponding reporting period.

3.3.1.1. Transaction processing report (RT 900 and RT 911)

RT 900 sends the following types of notifications:

• successfully processed transactions for the CESG and the CLB
• confirmation of the CESG paid on contributions
• confirmation of the CLB
• refusal reasons for the CESG and the CLB
• other transactions

RT 911 sends the following types of notifications:

• successfully processed BCTESG transactions
• confirmation of BCTESG payments
• refusal reasons for the BCTESG
• other transactions

The "transaction origin" field in a record indicates why the CESP system generated the record in the transaction processing report. The CESP system generates most of the RT 900 and RT 911 in response to promoter transactions. It returns a transaction origin of "0" (promoter initiated) for these records. Promoters can use these records to determine the processing status of each submitted transaction.

Promoters may also receive records in their transaction processing reports for other reasons. The transaction origin field for these situations would have a code other than "0" (not "promoter initiated"). These records may also include data required to update RESP notional accounts. For example:

• a CESP promoter support officer initiates a manual intervention
• the CESP system performs an automatic re‑adjudication
• the CRA reassesses a beneficiary’s eligibility for incentives
• the CLB is paid for the current benefit year

3.3.1.2. Transaction error report (RT 800)

RT 800 advises that an error is present in a transaction. This includes notice that validation has failed or information submitted is missing, incorrect, or incorrectly formatted. The record is rejected and must be corrected and resubmitted.

RESP promoters are responsible for correcting errors and resubmitting updated transactions to the CESP system.

For more information, refer to Appendix E. Understanding error codes.

3.3.1.3. Severe error report (RT 850)

RT 850 advises that a record was rejected and must be corrected and resubmitted. Severe errors can occur when:

• transactions with the same BN and Transaction ID already exist (the most frequent cause of severe errors)
• the record type is invalid
• the BN is not 15 characters long, or
• the Transaction ID is missing

Once RESP promoters have passed industry testing, their systems are less likely to generate transactions with severe errors.

3.3.1.4. SIN validation report (RT 920)

RT 920 advises that a beneficiary SIN is not usable, usable or linked. This report comes after the monthly SIR validation of all beneficiary SINs that are already in the CESP system. If there are no SIN issues, that promoter will not receive a SIN validation report. For more information, refer to section 3.4.2. SIN validation reports (RT 920).

3.3.1.5. Contract registration report (RT 950)

RT 950 indicates the registration status of contracts. Promoters should not consider a new contract to be "registerable" at the CRA until the CESP system returns an RT 950 with the "registration status" field set to "1" (registerable). For more information, refer to section 3.4.1. Transactions required to set up an RESP.

3.3.1.6. Production processing results report

The production processing results report gives a breakdown of all transaction types processed and the error rate for each type. This report is a PDF file sent in English and French.

3.4.1.1. Contract information (100‑01)

In contract information transactions (100‑01), the "individual/sibling only" field (position 103) is the only other field in addition to the first 7 mandatory fields for all promoter transactions. This field must be "1" (Yes) for the CESP system to pay the following incentives:

• Additional CESG
• CLB
• BCTESG

3.4.1.2. Beneficiary information (200‑03)

The following beneficiary information in 200‑03 transactions must pass validation at SIR:

• SIN
• given name
• surname
• date of birth
• gender

The CESP system does a preliminary validation of 200‑03 transactions before sending the beneficiary information for validation at SIR.

If it is mathematically impossible for the SIN to be valid, the CESP system rejects the 200‑03 transaction. It will generate an RT 800 with an error code of 7006 (invalid SIN).

There could be situations where the SIN had already been set up for a beneficiary in the CESP system but the birth years do not match. When this situation occurs, the CESP system rejects the 200‑03 transaction and generates an RT 800 with an error code of 7000 (invalid date).

If the beneficiary information in a 200‑03 transaction passes SIR validation, the CESP system generates a corresponding RT 900 in the transaction processing report. This informs the promoter that the beneficiary has been set up successfully in the CESP system. At that point, financial transactions may be successfully processed for this beneficiary SIN. If the beneficiary information in a 200‑03 transaction fails SIR validation, the CESP system generates a corresponding RT 800 in the transaction error report.

The CESP system processes the financial transactions for a beneficiary only if the 200‑03 transaction has been successfully processed and the beneficiary is established in the CESP system. Otherwise, all the financial transactions for the corresponding beneficiary SIN will be rejected with a 7001 or a 7031 error code.

On average, 80% of rejected transactions occur because beneficiary information has failed SIR validation. Promoters can reduce error rates by ensuring that beneficiary information is accurate before submitting 200‑03 transactions to the CESP system.

The CESP system processes non‑financial transactions before processing financial transactions. Therefore, promoters can submit their 200‑03 transactions in the same file as the associated financial transactions for a beneficiary.

A 200‑03 transaction will be rejected with a 7006 error code (invalid SIN) if the SIN is correct but any of the other 4 "SIN" fields do not pass SIR validation. The 4 other "SIN" fields are given name, surname, date of birth or gender. The CESP system reports SIR validation results in an RT 800 to help promoters resolve rejected 200‑03 transactions with this error code. These SIR validation results appear from positions 76 to 80 in an RT 800.

For example, if the beneficiary given name is "Katrina" at SIR but the given name field in the 200‑03 transaction reported "Trina", the CESP system would generate an RT 800 in the transaction error report with:

• "SIN" as the field name in positions 42 to 71
• "7006" as the error code in positions 72 to 75, and
• "0" in position 77 to indicate the given name failed SIR validation

The fields for SIR validation results are blank when a beneficiary SIN fails the preliminary validation test by the CESP system.

3.4.1.3. Subscriber information (200‑04)

The CESP system must determine that it is mathematically possible for the subscriber SIN to be valid. However, the subscriber information is not validated at SIR.

3.4.2.1.  1 – SIN is not usable

A beneficiary will cease to receive incentive payments in an RESP until the promoter corrects the problem. They will need to resubmit a 200‑03 transaction for the beneficiary with usable SIN information. Contributions made for the beneficiary prior to the SIN being flagged at SIR could still attract the CESG. However, contributions made after this date would appear in the RT 900. They would receive a refusal reason N (SIN has been flagged by SIR) in the transaction processing report.

3.4.2.2.  2 – SIN is usable

SIR has removed a non‑usable flag for a beneficiary SIN already reported in a previous RT 920 in the SIN validation report. For example, this could occur if SIR temporarily froze a SIN and made it usable again at a later date.

3.4.2.3.  3 – Linked SIN

This happens when a beneficiary receives a new SIN to replace a previous SIN. The old SIN is linked to a new SIN. For example, an expired (temporary 900 series) SIN is linked to the new permanent SIN. All financial transactions submitted for the old SIN are rejected. The CESP informs the promoter using an RT 800 with a 7001 error code (invalid value) in the transaction error report.

3.4.3.1. Unregistered contracts monitoring report

Legislation prohibits paying incentives into non‑registered plans. Promoters are responsible for ensuring that contracts reach registerable status within timelines outlined in the CRA Information Circular IC93‑3R2:

"The effective date of registration of an ESP will be the date the plan was opened if all required plan information is sent electronically to the CESP system no later than 60 days after the end of the calendar year the plan was opened."

Promoters can use the unregistered contracts monitoring report to help them resolve contract registration issues. This report is available in November and April. This report is in addition to the contract registration report (RT 950).

The CESP sends unregistered contracts information to the CRA in October of the year after the contract was opened. This could lead to the following consequences:

• tax implications for subscribers
• loss of incentive payments for beneficiaries

The unregistered contracts monitoring reports are generated for financial transactions that may have received incentive payments. Separate reports in Excel format are sent to address 2 scenarios:

• transaction 100‑01 successfully processed
• transaction 100‑01 missing or rejected

3.4.3.2. SIN error monitoring report

Error monitoring reports are generated in April and October. They inform promoters about financial transactions repeatedly rejected (with error codes) in the past 6 months. The 200‑03 transaction was rejected for the associated beneficiary.

If the associated 200‑03 transaction was rejected with an error code 7006 (invalid SIN), the SIR validation results are also indicated in this report. This report is an Excel spreadsheet containing the following data for rejected financial transactions:

• beneficiary SIN
• contract ID
• specimen plan ID
• error code
• SIR validation results:
  • SIN
  • given name
  • surname
  • birth date
  • gender

3.4.3.3.  3‑year rule monitoring report

An incentive will not be paid if the transaction date for the corresponding financial record is more than 3 years before the date on which the promoter sends the transaction file to the CESP system. The sent date is recorded in the header record (RT 001) of the submitted file. Promoters must resolve errors and resubmit accurate financial transactions within the 3 year limit for incentives to be paid.

The 3‑year rule monitoring reports are created in April and October. They advise promoters about financial transactions that were rejected (with SIN‑related error codes) and may be at risk of failing the 3‑year rule in the next 4 to 10 months. This report is an Excel spreadsheet containing the following data for each rejected financial transaction:

• beneficiary SIN
• specimen plan ID
• transaction type
• contract ID
• transaction date
• beneficiary error:
  • SIN
  • given name
  • surname
  • birth date
  • gender

The latest SIR flags are provided only when the beneficiary error code is 7006 (invalid SIN). Otherwise, these fields will be blank.

Many financial transactions are rejected because the associated beneficiary has not yet been established in the CESP system. Promoters must have successfully processed a beneficiary information transaction (200‑03) before any incentives can be paid for the financial transactions of that beneficiary. This needs to be done for each beneficiary listed in this report.

3.5.1.1. Order of incentive payments

The CESP system pays incentives in the same order in which incentive requests are successfully processed, using a "first come, first served" approach. If multiple incentive requests for the same beneficiary are received in the same processing month, the transaction with the earliest transaction date is processed first. It will receive the incentive payment first.

3.5.3.1. Contract, beneficiary and subscriber information

To correct processed transactions with inaccurate information, promoters can submit new transactions to the CESP system for:

• the contract (100‑01)
• the beneficiary (200‑03)
• the subscriber (200‑04)

3.5.3.2. RT 400 transactions

If the CESP system processes inaccurate RT 400 transaction, the promoter must reverse this transaction. The promoter must then submit another transaction with the correct information. Reversals are permitted only to correct administrative errors on RT 400 transactions.

For example, a promoter might determine that a $1,000 contribution was processed by the CESP system with an inaccurate amount of $100. The promoter must reverse the original transaction ($100) and submit a new transaction with the correct contribution amount ($1,000).

Promoters can reverse an inaccurate RT 400 transaction by submitting a new transaction with the following key information.

The transaction that the promoter submits to reverse another transaction must have a new (unique) promoter transaction ID (positions 12 to 26).

The original promoter BN can be the business number of another promoter only if that promoter was:

• merged with, or
• acquired by the current promoter

In these situations, promoters must again pass industry testing. This is to demonstrate that their systems are able to reverse transactions that were submitted by the original promoter.

3.5.3.3. Requests for the BCTESG (411‑41)

If the CESP system successfully processed a request for the BCTESG that had an administrative error (example: wrong beneficiary):

• the promoter must submit a cancel BCTESG request transaction (411‑41) to the CESP system

This reverses the original request and the promoter could then submit a corrected BCTESG request transaction (4011‑40) if required.

3.5.4.1. Key fields for 400‑11

Promoters can request the CESG with a contribution transaction (400‑11) using the following key fields.

3.5.4.2. Key RT 900 fields for 400‑11

The CESP system acknowledges successfully processed 400‑11 transactions with an RT 900 in the transaction processing report. The following are RT 900 fields of interest for 400‑11 transactions.

If the grant requested field for a 400‑11 transaction is "1" (Yes), the CESP system will validate eligibility and pay the corresponding CESG amount. The amounts of Basic CESG and Additional CESG paid for a contribution are reported back to promoters. The CESP system reports them separately in different fields of the same RT 900. Promoters must have one notional account to track the total amount of Basic CESG and Additional CESG combined for all beneficiaries in an RESP. However, promoters may also maintain these accounts at the beneficiary level.

The CESP system informs promoters how much of each contribution attracted the CESG (assisted contributions) in an RT 900 of the transaction processing report. The RESP promoter must update this amount in the assisted contribution notional account. If applicable, promoters must calculate the remaining contribution amount (unassisted contribution) to update the unassisted contribution notional account. Subscribers must make each contribution in respect of one beneficiary. However, promoters must maintain each notional accounts for the assisted contributions and unassisted contributions at the plan level.

The promoter must maintain the notional account balance for assisted contributions and unassisted contributions. In the event of a transfer, they must record both of these notional account balances on the RESP transfer form. The assisted contribution notional account balance is also used to calculate the amount of CESG that must be repaid due to a withdrawal of contributions.

3.5.4.3. Transaction origins for the CESG

3.5.4.4. Beneficiary matching report for refusal reason 4

Promoters offering the Additional CESG may receive a beneficiary matching report for refusal reason 4. They would receive that with the other monthly reports generated by the CESP system. These reports include a record for each request that did not receive the Additional CESG due to refusal reason 4.

The beneficiary matching report is an Excel spreadsheet with the following columns for each record:

• year of the request
• beneficiary SIN
• contract ID
• beneficiary surname status
• beneficiary given name status
• beneficiary birth date status
• PCG/spouse SIN (for individual PCGs)
• PCG BN (for public PCGs)

For more information, refer to Appendix F. Understanding refusal reasons.

3.5.4.5. Common problems for 400‑11

1. Beneficiary not established in the system:
   • the beneficiary for whom a contribution (400‑11) was made has not yet been set up successfully in the CESP system. The contribution transaction is rejected with an error code 7001 or 7031 in an RT 800

   Resolution: For more information, refer to error codes 7001 and 7031 in Appendix E. Understanding error codes

2. Contract not set up correctly:
   • the "Individual/sibling only" field of the 100‑01 transaction should have been Yes (1) but was set up using No (0)
   • Additional CESG is requested using a 400‑11 transaction but payment is refused with a refusal reason J in an RT 900

   Resolution: For more information, refer to refusal reason J in Appendix F. Understanding refusal reasons

Prior to 2018, only the PCG could provide their name and SIN to request the Additional CESG. If the PCG’s cohabiting spouse or common‑law partner provided their information instead, the request would receive a refusal reason "L". In those situations, the RESP promoter would have had to contact the subscriber and collect the PCG’s information on a new application form. They would then either submit a 511‑12 transaction, or reverse and resubmit the original 400‑11 transaction with the updated PCG information.

As of 2018, either the PCG or their cohabiting spouse or common‑law partner, if applicable, can provide their information to request the Additional CESG. The RESP promoter can submit this PCG/spouse information and not receive a refusal reason "L" if this information matches the CRA records.

3.5.5.1. Key fields for 511‑12

3.5.5.2. Key RT 900 fields for 511‑12

Each processed 511‑12 transaction generates one RT 900 with a transaction origin of 0. It will also generate 2 RT 900 with a transaction origin of 8 in the transaction processing report. The following are RT 900 fields of interest for 511‑12 transactions.

3.5.5.3. Alternative to using 511‑12

It is not mandatory for a promoter to use the 511‑12 transaction to request the corresponding Additional CESG on a successfully processed contribution transaction. Promoters may choose instead to reverse the original 400‑11 transaction and resubmit a new 400‑11 transaction with the required PCG/spouse information.

3.5.6.1. Key fields for 400‑24

When terminating an RESP, promoters should submit a 400‑24 transaction, for each beneficiary with an active CLB request in the RESP. They should also set the grant requested field to "0" (No). While this will stop new CLB payments to this RESP, it will not prevent beneficiaries from receiving the CLB payments in another RESP.

3.5.6.2. Key RT 900 fields for 400‑24

The CESP system acknowledges successfully processed 400‑24 transactions with an RT 900 in the transaction processing report. The following are RT 900 fields of interest for 400‑24 transactions.

3.5.6.3. Transaction origins for the CLB

3.5.6.4. CLB resubmissions monitoring report

The CESP system will refuse payment for a CLB request transaction (400‑24) when the PCG or the PCG’s spouse or common‑law partner information does not match beneficiary information during the CRA validation process. This occurs most frequently when the beneficiary’s information does not match the CRA records, or when the CRA record does not yet exist when the beneficiary matching validation takes place.

Quarterly CLB resubmission monitoring reports inform promoters about CLB requests originally refused but may now pass the CRA validation using the same information for the beneficiary and the PCG or the PCG’s cohabiting spouse or common‑law partner. This report is an excel spreadsheet with the following columns for each report record:

• beneficiary SIN
• contract ID

3.5.6.5. Common problems for 400‑24

1. Beneficiary not established in the system:
   • the beneficiary for whom the CLB was requested has not yet been successfully set up in the CESP system. The CLB request (400‑24) transaction is rejected with an error code 7001 or 7031 in an RT 800

   Resolution: For more information, refer to error code 7001 or 7031 in Appendix E. Understanding error codes

2. Contract not set up correctly:
   • the "Individual/Sibling Only" field of the 100‑01 transaction should have been Yes (1) but was set up using No (0)
   • CLB is requested for the beneficiary using a 400‑24 transaction but payment is rejected with an error code 1010 in an RT 800

   Resolution: For more information, refer to error code 1010 in Appendix E. Understanding error codes

Prior to 2018, only the PCG could provide information to request the CLB. If the PCG’s cohabiting spouse or common‑law partner provided their information instead, the CESP system would process the request with a refusal reason "L". The RESP promoter would then have to contact the subscriber and collect the PCG’s information on a new application form ESDC SDE 0093. They would then submit a new 400‑24 transaction to provide the updated PCG information.

As of 2018, either the PCG or their cohabiting spouse or common‑law partner, if applicable, can provide their information on the application form ESDC SDE 0093. The RESP promoter can submit this PCG/spouse information and not receive a refusal reason "L" if it matches the CRA records.

As of January 1, 2022, promoters must use the new application form (ESDC SDE 0107) for beneficiaries between 18 and 20 years of age who have not yet received the CLB and wish to apply for it. The PCG’s information or that of their cohabitating spouse or common law partner is not gathered on form ESDC SDE 0107.

3.5.7.1. Key fields for 411‑40 (BCTESG request)

The following are key fields for BCTESG request transactions.

Transaction date: Promoters must use the date on the BCTESG application form for the transaction date in BCTESG request transactions (411‑40). This is a key date to validate both refusal reasons and error codes.

3.5.7.2. Key fields for 411‑41 (Cancel BCTESG request)

The following are key fields for cancel BCTESG request transactions.

3.5.7.3. BCTESG time constraints

Refusal reason 3 (age of beneficiary): Subscribers have 3 years to apply for the BCTESG once the beneficiary reaches a certain age. The CESP system will send promoters a refusal reason 3 (age of beneficiary) in certain circumstances. This refusal reason is sent for each request that falls outside the corresponding 3 year application window specified in the table below. The transaction date for a BCTESG request is the date on which the subscriber signs the BCTESG application form.

Error code 7042: All BCTESG requests for beneficiaries born before January 1, 2006, will be rejected with error code 7042.

Error code 7041: All BCTESG requests with transaction dates prior to August 15, 2015, will be rejected with error code 7041.

Refusal reason D: Promoters have 3 years to successfully process a BCTESG request transaction. They must send a file to the CESP system for processing no more than 3 years after the transaction date of the BCTESG request in the file. The CESP system sends promoters a refusal reason D (late transaction) for BCTESG requests processed after this 3 year limit.

3.5.7.4. Key RT 911 fields for RT 411

The CESP system will acknowledge each successfully processed BCTESG request transaction (411‑40) and cancel BCTESG request transaction (411‑41). The system will do so by sending promoters a corresponding RT 911 in their monthly transaction processing report.

The CESP system will also generate records in response to other transactions if they have an impact on the BCTESG account balance in an RESP. For example, the CESP system sends one RT 900 and one RT 911 together for the same financial transaction (RT 400). This will occur when the BCTESG EAP amount or the BCTESG amount is greater than 0.

The following RT 911 fields are of interest for BCTESG transactions.

3.5.7.5. Common problems for BCTESG transactions (RT 411)

1. Beneficiary not established in the system:
   • the beneficiary for whom a BCTESG request (411‑40) was made has not been successfully set up in the CESP system. The BCTESG request transaction is rejected with an error code 7001 or 7031 in an RT 800

   Resolution: For more information, refer to error codes 7001 and 7031 in Appendix E. Understanding error codes

2. Contract not set up correctly:
   • the "individual/sibling only" field of the 100‑01 transaction should have been Yes (1) but was set up using No (0)
   • the BCTESG is requested using a 411‑40 transaction, but the request is rejected with an error code 1010 in an RT 800

   Resolution: For more information, refer to error code 1010 in Appendix E. Understanding error codes

3. Late application form:
   • a promoter submits a BCTESG request (411‑40) with a transaction date outside of the 3 year application window
   • the BCTESG request is processed, but the BCTESG payment is refused with a refusal reason 3 in an RT 911

   Resolution: For more information, refer to refusal reason 3 in Appendix F. Understanding refusal reasons. Promoters should inform subscribers that they must complete the BCTESG application form within the required application window (refer to section 3.5.7.3. BCTESG time constraints)

3.5.8.1. Key fields for 400‑13

The following are key fields for EAP transactions (400‑13).

3.5.8.2. Key RT 900 fields for 400‑13

The CESP system will acknowledge each successfully processed EAP transaction by sending promoters a corresponding RT 900 in their monthly transaction processing report. The following are key fields in these records.

3.5.8.3. Key RT 911 fields for EAPs with a BCTESG amount

If an EAP transaction includes a non‑zero BCTESG amount, the CESP system will acknowledge a successfully processed EAP transaction. It will send promoters a corresponding RT 911 in their monthly transaction processing report. The following are key fields in these records.

3.5.8.4. Common problems for 400‑13 transactions

1. Beneficiary not established in the system:
   • the beneficiary for whom an EAP is paid has not yet been set up in the CESP system. The EAP transaction is rejected with an error code 7001 or 7031 in an RT 800

   Resolution: For more information, refer to error codes 7001 or 7031 in Appendix E. Understanding error codes

2. Mandatory data is missing:
   • data is missing from mandatory fields submitted in an EAP transaction. The EAP transaction is rejected with a 7005 error code in an RT 800

   Resolution: For more information, refer to error code 7005 in Appendix E. Understanding error codes

3.5.9.1. Key fields for 400‑14

The following are key fields for a PSE contribution withdrawal (400‑14).

3.5.9.2. Key RT 900 fields for 400‑14

The CESP system will acknowledge each successfully processed PSE contribution withdrawal transaction. It will send promoters a corresponding RT 900 in their monthly transaction processing report. The following are key fields in these records.

3.5.9.3. Common problems for 400‑14 transactions

1. Beneficiary not established in the system:
   • the beneficiary identified in the PSE contribution withdrawal transaction has not yet been successfully set up in the CESP system. The 400‑14 is rejected with an error code 7001 or 7031 in an RT 800
   Resolution: For more information, refer to error code 7001 or 7031 in Appendix E. Understanding error codes
2. Mandatory data is missing:
   • data is missing from mandatory fields in a PSE contribution withdrawal transaction. The 400‑14 is rejected with an error code 7005 in an RT 800

   Resolution: For more information, refer to error code 7005 in Appendix E. Understanding error codes

3.5.10.1. Partial transfers

Subscribers must transfer the same proportion from each of the notional account balances (the assisted contributions, unassisted contributions, the CESG and accumulated incomes), with the exception of the CLB and the BCTESG.

Subscribers can choose to transfer all, some or none of the CLB and the BCTESG.

3.5.10.2. Special transfer rules for the CLB

One CLB account per beneficiary: Other incentives have a single account balance for all beneficiaries at the plan level. For the CLB, promoters must maintain notional accounts for each individual beneficiary in a family RESP. The transfer of the CLB can only happen between the CLB notional accounts of the same beneficiary. Therefore, promoters must update the CLB notional account for each individual beneficiary after a transfer.

3.5.10.3. Key fields for transfer transactions

The following are key fields for transfer transactions (400‑19 or 400‑23).

3.5.10.4. Key RT 900 fields for transfer transactions

The CESP system will acknowledge each successfully processed transfer transaction (400‑19 or 400‑23). It will send promoters a corresponding RT 900 in their monthly transaction processing report. The following are key fields in these records.

3.5.10.5. Key RT 911 fields for a transfer of BCTESG

If a transfer transaction includes a non‑zero BCTESG amount, the CESP system will acknowledge a successfully processed transfer transaction. It will send promoters a corresponding RT 911 in their monthly transaction processing report. The following are key fields in these records.

3.5.10.6. Common problems with transfers

1. Other specimen plan ID is inaccurate:
   • one promoter does not record the accurate specimen plan ID for their RESP on the RESP transfer form. The other promoter enters inaccurate information for the "other specimen plan ID" in their system. When the other promoter submits their transfer transaction to the CESP system, it is rejected with an error code 1005 in an RT 800

Resolution: For more information, refer to error code 1005 in Appendix E. Understanding error codes. The promoter that received an error code 1005 must contact the other promoter. They need to obtain the accurate specimen plan ID for their RESP. They will then resubmit a new transfer transaction to the CESP system with the accurate specimen plan ID.

3.5.11.1. Impact of repayments on future payments

CESG grant room: The CESG grant room is reduced for a beneficiary each time one of these incentives is paid into an RESP for the beneficiary. However, the CESG repayments are at the plan level. Therefore, the grant room of individual beneficiaries is not restored by the repaid amounts of CESG.

BCTESG: Repaid BCTESG amounts are lost for the beneficiaries named in the RESP. Subscribers cannot request these BCTESG amounts again for the affected beneficiaries.

CLB entitlement: CLB repayments are at the beneficiary level. They do not affect a beneficiary’s lifetime entitlement for the CLB. It is possible for a beneficiary to receive again the CLB amounts repaid for that beneficiary.

3.5.11.2. Key fields for 400‑21

The following are key fields for incentive repayment transactions (400‑21).

As the CLB is beneficiary specific, promoters must submit a separate repayment transaction for each beneficiary with CLB amounts in a family RESP. All other incentive repayments are at the plan level. They may be combined in a single repayment transaction (400‑21) without providing a particular beneficiary SIN.

3.5.11.3. Repayment reasons

3.5.11.4. Mandatory transaction when an RESP is terminated

Promoters must inform the CESP system when they terminate an RESP for any reason. They will submit an incentive repayment transaction (400‑21) using the "contract termination" repayment reason (03).

Even if there are no incentives in an RESP when they terminate the plan, they must still report the termination to the CESP system. The incentive amount is set to 0 in the 400‑21 transaction.

3.5.11.5. Key RT 900 fields for 400‑21

The CESP system will acknowledge each successfully processed repayment transaction (400‑21) by sending promoters a corresponding RT 900 in their monthly transaction processing report. The following are key fields in these RT 900.

3.5.11.6. Key RT 911 fields for a BCTESG repayment

If a repayment transaction includes a non‑zero BCTESG amount, the CESP system will acknowledge a successfully processed repayment transaction. It will send promoters a corresponding RT 911 in their monthly transaction processing report. The following are key fields in these records.

3.5.11.7. Common problems for 400‑21

1. Promoters do not notify the CESP system about terminations:
   • a subscriber transferred all of the funds in an RESP to another RESP administered by another promoter and terminates the plan. The relinquishing promoter submitted only a transfer out (400‑23) transaction to the CESP system. That promoter does not also submit a mandatory repayment transaction (400‑21) with a repayment reason 03 (contract termination). This RESP may be identified as a compliance issue in a CESP compliance review

   Resolution: The promoter of the relinquishing RESP must submit a repayment transaction (400‑21) with a repayment reason of 03 (contract termination) after updating all notional account balances to 0. All repayment amounts will be 0 in this transaction

2. Using reversals instead of repayments:
   • a subscriber realizes that some contributions for a beneficiary did not receive the CESG due to the annual limit (refusal reason 1). The subscriber wants to withdraw the unassisted contributions (contributions that did not receive grant). The subscriber would like the promoter to reverse all unassisted contributions to avoid having to repay the CESG. As this is not an administrative error, the promoter cannot reverse the unassisted contributions

   Resolution: The promoter should advise the subscriber that nothing can be done about the unassisted contributions that year. The promoter should also explain how the annual CESG limit per beneficiary applies across all RESPs. The promoter will help the subscriber(s) plan contributions in subsequent years

3. Using repayments instead of reversals:
   • due to an administrative error made by the promoter, a contribution transaction (400‑11) that received the CESG was submitted for the wrong beneficiary in a family RESP. The promoter submits a repayment transaction (400‑21) to repay the CESG amount received for the wrong beneficiary. The promoter then submits a new contribution transaction for the correct beneficiary. The original beneficiary’s RESP contribution limits, the CESG lifetime limits and the CESG grant room are not restored after a repayment transaction

   Resolution: The promoter should have reversed the 400‑11 transaction instead of using a repayment transaction. To correct the problem, the promoter should now reverse the original contribution transaction and also reverse the repayment transaction

3.5.12.1. Key fields for 400‑22

The following are key fields in a termination adjustment transaction (400‑22).

3.5.12.2. Key RT 900 fields for 400‑22

The CESP system will acknowledge each successfully processed termination adjustment transaction (400‑22). It will send promoters a corresponding RT 900 in their monthly transaction processing report. The following are key fields in these RT 900.

3.5.12.3. Key RT 911 fields for the BCTESG portion of termination adjustments

If a termination adjustment transaction includes a non‑zero BCTESG amount, the CESP system will acknowledge a successfully processed transaction. It will send the promoter a corresponding RT 911 in their monthly transaction processing report. The following are key fields in these records.

3.5.12.4. Withdrawing contributions after a loss

Order of losses: Promoters must apply losses to earnings first and then to contributions. Once all contributions in the RESP have been depleted, any remaining loss is considered to be applied proportionally to the incentives remaining. This means that the loss will apply proportionally to the federal and provincial education savings incentives remaining in the RESP.

Fair market value test: When subscribers request contribution withdrawals for any reason, promoters must verify the RESP fair market value. They must ensure that it is large enough for the withdrawal amount. This applies even when the RESP is not being terminated and includes PSE contribution withdrawals.

Contribution withdrawal limit: Promoters must subtract all incentive notional account balances from the fair market value to find the maximum contribution withdrawal amount.

For example, a subscriber asked to return all contributions when the promoter terminates his RESP. The following bulleted list shows the notional accounts and the fair market value for the RESP at that time:

• RESP fair market value: $2,600
• Contributions: $2,500
• CESG: $1,000
• CLB: $600

In this example, the combined incentive notional accounts would be $1,600 which means the contribution limit would be $1,000 (subtract $1,600 from $2,600). Therefore, the promoter could only return $1,000 of contributions to the subscriber after repaying all incentives remaining in the RESP.