Interface transaction standards - Canada Education Savings Program

3.1 File format overview

Senders can submit 1 or more files for processing in a reporting period. The file name is structured to allow several files to be reported on 1 day. In addition to the sender BN and the 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 by the ITS, 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 CESP receives from a sender after the data delivery cut-off date will be held and processed in the next reporting period, unless otherwise notified. The sender is responsible for ensuring that files arrive in a timely manner to be processed within a particular processing period.

3.2 Record format overview

Once all certification requirements are met, it is necessary for the sender to inform the CESP of all relevant RESP activity. Contract activity must be reported to the CESP electronically as follows:

• contract information informing the CESP of the non-financial aspects of the RESP, such as subscriber and beneficiary information (personal information) and contract information (details of the contract)
• financial transactions informing the CESP of contributions, post-secondary education (PSE) withdrawals, educational assistance payments (EAP), repayment transactions, transfers, termination adjustments, requests for CLB payments, requests for BCTESG payments and reversals of these transactions. In the case of BCTESG, a cancel request is used in place of a reversal

Transactions submitted to the CESP are categorised by record type and transaction type. For example, contract information is reported using a record type 100, while beneficiary and subscriber information is reported using a record type 200. All financial transactions fall into record types 400 and 411. Within each record type are 1 or more transaction types.

When the CESP receives a file for processing, the format and content of each transaction is validated (please 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 sender will be responsible for performing the necessary corrections and resubmitting the data. The sender will receive confirmation of acceptance in the processing reports that the CESP sends back to the sender. If any transaction was rejected, it will appear in the error report or the severe error report, depending on the nature of the error. For RESP contracts that have a 60-day "cooling-off" period, transactions should not be forwarded to the CESP until after this period has expired.

3.3 Transaction reporting sequence

Transactions must be submitted in a logical sequence. A beneficiary record must be processed before the CESP system can process financial transactions for that beneficiary. Senders must register contracts before submitting financial transactions for those contracts. Since the CESP system processes transactions in that sequence, contract, beneficiary, and financial transactions can be reported in the same transaction file.

3.4 Transaction date

Each transaction is reported with a transaction date. This date refers to the date on which the transaction occurred between the subscriber and the promoter. For example, the date on a contract transaction would be the date on which the subscriber entered into the contract. For a contribution transaction, the transaction date is the date the contribution was made by the subscriber to the RESP contract.

3.5 Late transaction processing

The CESP expects senders to report all transactions in the reporting period following the period in which the transaction occurred.

Financial transactions requesting grant or bond money, such as transactions 400-11, 400-24 and 411-40 with a transaction date earlier than 3 years, when compared to the date sent in the header record (001) of the file, will not receive payment due to the tardiness of the transaction.

3.6 Reporting period cut-off date

The CESP processes files and pays grant/bond on a monthly basis. Schedules with processing dates (transaction periods, file submission cut-off and grant/bond payment dates) are sent out to the sender 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. Senders are given 4 business days after the reporting period ends to finalize their file(s) to be sent for processing. Senders are not to include any transactions that occurred after the last day of the reporting period.

3.7 Transaction information

As can be seen in the detailed description of the record types, some record types are used for more than 1 purpose. Record type 200 is used to report both beneficiary and subscriber information and record type 400 or 411 is used for reporting several different types of financial transactions. In each case, the specific use of the record is indicated by the transaction type. The information requirements of the various transaction types within a record may differ, resulting in fields that are not required in some transactions but are mandatory in others.

Where fields reported in a transaction are unnecessary for that transaction, like an educational institution reported in a contribution transaction, it could lead to a question as to the intent of the sender. Did the sender mean to report a contribution and inadvertently added an educational institution or did the sender mean to report an EAP and accidentally miscoded the transaction? Senders are advised that inadvertently reporting unnecessary information in a transaction may not result in the rejection of that transaction. In all types of transactions, only information pertinent to that particular record type will be involved in processing, all unnecessary information will be ignored.

4.1 Record type 100 - Contract information

Senders must submit a contract information transaction (record type 100, transaction type 01) in order to establish the contract in the CESP system and to register the contract. The CESP collects the information required to register an RESP with the CRA under the Income Tax Act and acknowledges eligibility of registration of the contract on behalf of the CRA.

Before registration of a contract can occur, the sender must also submit transactions that provide the CESP with information on the beneficiary (record type 200, transaction type 03) and the subscriber (record type 200, transaction type 04).

In addition to the record type 900 acknowledging receipt of the contract information transactions, a .reg processing report (contract registration report type 950) is sent to the sender to indicate that all the contract information, subscriber information and beneficiary information transactions have been successfully processed and should meet the conditions for registration at the CRA. The beneficiary does not have to pass Social Insurance Registry (SIR) validation in order to be considered processed.

Promoters should note that a rejected contract information transaction needs to be revised or corrected and re-sent to the CESP.

Additional CESG, CLB and BCTESG request transactions must be on an individual/sibling only contract to attract grant or bond payment. Promoters must submit new record type 100 contract information transactions with the individual/sibling only designation for all existing contracts in order for these contracts to be eligible to receive Additional CESG, CLB or BCTESG.

4.2 Record type 200, transaction type 03 - Beneficiary information

Senders must submit sufficient information to register a contract including a beneficiary information transaction (record type 200, transaction type 03) prior to sending financial transactions associated with the beneficiary. Refer to section 5.5 which states the transactions required to register a contract.

The return of a processing report (.pro) or an error report (.err) will confirm the acceptance or rejection of the beneficiary record. A beneficiary information transaction may be rejected for the following reasons:

• the beneficiary social insurance number (SIN) must be present and valid. The CESP validates the SIN, given name, surname, date of birth and gender of all beneficiaries with the Social Insurance Registry (SIR). If a beneficiary fails validation at SIR, the transaction is rejected and a beneficiary account is not created in the CESP system. In order for a beneficiary account to be created, senders must resubmit the beneficiary information transaction with the correct information. To minimise errors, the beneficiary’s given name and surname should be submitted to the CESP exactly as they appear on the SIN documentation
• the custodial parent's name is mandatory information on a beneficiary information transaction only if the beneficiary is under the age of 19
• other mandatory information missing from the beneficiary information transaction will also cause the transaction to reject. Again, the transaction must be corrected and resubmitted to the CESP before financial transactions, such as contributions, can be processed and grant/bond can be paid. Any rejections appear in the error report that the CESP returns to the sender

Once the contract has been established and registered and a beneficiary is processed by the CESP system, senders must report financial activities pertaining to that beneficiary and contract.

New beneficiaries or replacement beneficiaries added to already existing contracts must be submitted using a new beneficiary information transaction. Promoters do not report the removal of either subscribers or beneficiaries from contracts. The successful processing of each of these transactions is reported in record type 900.

4.3 Record type 200, transaction type 04 - Subscriber information

A subscriber information transaction (record type 200, transaction type 04) may be rejected for missing or invalid information that is mandatory for processing. If a subscriber information transaction is rejected, the corresponding contract cannot be registered. Any rejection appears in the error report (transaction error report type 800) which the CESP returns to the sender. The correction and resubmission of the transaction is required before the contract can be registered.

Contracts created before January 1, 1999 do not require a subscriber SIN. For contracts created on or after January 1, 1999, a subscriber SIN must be provided. The subscriber SIN must be numerically valid. In order to keep contract information updated on successfully processed beneficiary or subscriber information transactions (such as change of address), senders should submit a new beneficiary/subscriber information transaction with the updated information.

4.4 Record type 400 - Financial transaction

To ensure the proper payment of the CESG, Additional CESG and CLB, senders must report to the CESP the financial transactions for all beneficiaries and contracts. Financial transactions include all movements of funds in and out of an RESP, but not the growth or investment activities. The CESP bases the payment of requested monies on the reported transactions. A contract must be registered through the CESP before senders can submit any of the following transactions:

• contributions/Additional CESG
• educational assistance payments
• Post-Secondary Education (PSE) withdrawals
• grant repayment, including contract terminations
• transfers
• termination adjustments
• Canada Learning Bond requests

4.5 Record type 411 – BCTESG transaction

4.6 Record type 511 - PCG/spouse information transaction

During promoter consultation sessions, a requirement was identified that would allow promoters to submit PCG/spouse information for previously processed CESG request transactions. Rather than reversing the original 400-11 contribution transaction and submitting a new 400-11 contribution transaction containing the missing or erroneous PCG/spouse information, promoters can submit this information via the 511-12 transaction. This record type can be used for RESP contributions made on or after January 1, 2005 where the original transaction was missing PCG/spouse information, or the information submitted was incorrect and thus did not receive the Additional CESG.

4.7 Record type 700 - Summary reporting

As part of its mandate, the CESP must report on its success in meeting its goals to various organisations within the federal government. Since the primary goal of the CESP is to encourage Canadians to save for their children's post-secondary education, the growth in the total assets available to those beneficiaries for post-secondary education is a good measure of the success of the CESP.

Senders must send records of type 700 to the CESP once per reporting period giving the market value of each RESP contract under their management as of the last business day of the month. Record type 700 can be submitted to the CESP anytime within the following month. The summary transactions are sent in a separate file containing only records of type 700 (as well as the header and trailer, of course).

5.1 Record type 800 - Transaction error report

This document details the format for each transaction type, and provides the sender with the validation rules for those types. If transactions are not submitted within the guidelines outlined in this document, the transactions are subject to rejection. It is the responsibility of the sender to perform the necessary corrections and resubmit the data.

Each transaction error, whether due to problems in format or invalid data, is reported back to the sender for correction and resubmission. This is done electronically via the transaction error report.

The error report contains the transactions submitted to the CESP by a sender that have not been accepted due to the following reasons:

• failure to correctly format the transaction
• failure to supply the necessary information for mandatory fields, or
• failure to comply with business rules

The complete list of error codes is outlined in the section on transaction error codes in Appendix A.

Validation is always done first on the format of the transaction (please see each record type in the ITS for validation rules), then on the transaction's compliance with the business rules. If a transaction is rejected for format problems, a compliance validation is not performed on the transaction. Therefore, a transaction rejected for format may also contain a business compliance error not specified in the error report.

Errors are reported individually for each field in each record whenever they are detected. The field name and an error code describing the error encountered for that field identify each error. Many error messages can be generated for a single record if it contains many formatting errors.

Transactions that conflict with the business rules are also identified and reported. Only a single business error is reported per transaction. For business errors the transaction error code describes the error. Business rules are not validated for transactions that contain data format errors.

When senders receive an error report, it is their responsibility to correct the transaction and resubmit it for processing. When resubmitting, the promoter transaction ID must not be reused. A new identifier is required.

5.2 Record type 850 - Severe error report

A severe error report contains transactions that have been previously sent to the CESP (the BN and the promoter transaction ID already exist in the CESP system) or contain an invalid record type. Rejection will also occur if the BN is not 15 characters long or the promoter transaction ID is not provided on the transaction.

When senders receive a severe error report, it is their responsibility to correct the transaction and resubmit it for processing. When resubmitting, the promoter transaction ID must not be reused. A new identifier is required.

5.3 Record types 900 and 911 - Transaction processing report

At the end of each processing period, the CESP sends a transaction processing report to the sender with a record for every successfully processed transaction. This report contains 2 record types: a record type 900 and a record type 911 for BCTESG information. Each record provides detailed results of the processing of financial transactions submitted (such as how much grant was attracted by each contribution, CLB or BCTESG request, or how much grant, bond or BCTESG was repaid). The report is the CESP’s confirmation to the sender that the submitted transactions were correctly formatted, contained all the mandatory information and passed all the necessary business rules. The transaction processing report also lists all contract, beneficiary, and subscriber information that was successfully processed.

The processing of a sender’s file(s) results in a series of grant/bond payments and repayments. Repayments are netted out from the payments, generally resulting in a payment to the sender. The payment will be automatically deposited into the sender’s account according to the banking information supplied to the CESP. Senders are to use the transaction processing report to update their own contract notional accounts.

The record type 900 indicates the effect the transaction had on the payment received by the sender. The payment requisitioned flag tells the sender if the 900 record is a payment or repayment of grant, or CLB to or from the CESP. In this case the payment requisitioned flag would be set to “yes”, signifying that this transaction affects the amount paid to the sender. In the case of an EAP, PSE contribution withdrawal, transfer or termination adjustment, there is no money moving between the promoter and the CESP so the payment requisitioned flag would be set to “no” signifying that this transaction does not affect the amount paid to the sender.

In the case of the record type 911, the payment requisition flag is set to “yes” if the 911 record is for a payment or repayment of BCTESG or a cancellation of BCTESG. When the 911 record is for the BCTESG portion of an EAP, transfer or termination adjustment, there is no money moving between the promoter and the CESP so the payment requisitioned flag would be set to “no”. The promoter can then reconcile all transactions with the flag set against the payment received from the CESP.

5.4 Record type 920 – SIN validation report

As part of the CESP’s ongoing efforts to improve program integrity, CESP will verify its beneficiary SIN information with the SIR on a monthly basis. As a result of this monthly SIN validation, certain beneficiary SINs will be identified (flagged) by SIR as not useable. In order to help RESP promoters identify the “not useable” SINs, the CESP sends a SIN validation report (svr) each month. This file will contain a new record type called the SIN validation report record (920).

5.5 Record type 950 - Contract registration report

The CESP acknowledges every contract eligible for registration in the contract registration report for the reporting period. This indicates whether or not all the contract information, subscriber information and beneficiary information transactions have been successfully processed and met the conditions for registration at the CRA.

5.6 Record type 960 - Referral report

Promoters participating in the education savings referral service will receive a referral report on a daily basis (including weekends and holidays) from the CESP. The referral report could contain 1 or more Referral Report records (960) which will contain the information for an individual who is interested in acquiring more information about RESPs, the CESG and the CLB, in order to consider opening an RESP for their child and applying for the education savings incentives. Multiple births, for example twins, would result in a referral report record for each child.

5.7 Mergers

Corporate purchases, amalgamations, realignments and other such business transactions occur frequently within the financial services and RESP industry. These changes are typically accompanied by revisions to the relevant business information, such as a new business number (BN), changes to the types of specimen plans offered, change of trustee, or company name changes, etc.

The CESP needs to be made aware of these corporate changes as early as possible. This is necessary to allow sufficient time to determine if a new CESP promoter or trustee agreement is required and, to make the required updates to the CESP system to ensure grant and bond payments continue uninterrupted.

6.1 Scope

This document describes the data interface for the exchange of information between the CESP and financial service organisations applying for the CESG, Additional CESG, CLB and BCTESG. This specification is intended for use in support of system development to implement data interchange with the CESP system.

This document is the standard by which information is exchanged with the financial services industry for the application and administration of the CESG, Additional CESG, CLB and BCTESG. Data integrity rules are described in detail in this document. Descriptions of the business and general rules under which data is processed within the CESP 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 specification and are found in Data Interface Operations and Connectivity. Operational functionality includes the following:

• logging of files
• authentication of sender
• transmission verification
• transmission mechanisms

Detailed operational instructions concerning reporting schedules and methods of transfer of information may be obtained from:

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-3624

6.2 CESP transaction processing record format overview

This specification describes a data interface that is based on the exchange of bulk data files. Senders are required to conform to the record formats and rules specified in the ITS as well as other data interchange rules described in the Data Interface Operations and Connectivity.

The ITS consists of both input and output data record formats. Input records are used to record contract information, record beneficiary information and report financial transactions. Output records report the status of reported data in the form of transaction processing reports and error reports on a record by record basis.

6.3 Logical record types

Source transactions are identified by a record type code as outlined in the following table.

6.4 File/record structure

All transaction files have a header record containing standard identification details. Files have a trailer record containing a control 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 on the same file.

6.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. If character data is received right justified, the CESP system will convert it to left justify and transaction reports will show the data left justified. A business number 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 sender BN field the record is rejected.

Numeric data is right justified with leading zeroes.

Most amount fields are standardised at 9 digits with 2 implied 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 12 characters $9,999,999,999.99.

List-type data fields use code tables whenever practical (such as province codes and error codes).

All record types 100, 200, 400, 411 and 511 include a transaction type code. Separate codes are used with each type of transaction in order to identify the specific processing requirements.

6.6 Record separators

Records within files must be separated by a record separator character(s). Record separator characters vary depending on the operating system of the originating system. The CESP transfer process replaces the carriage return (CR, decimal value 13) record separator character with the UNIX new line character (NL, decimal value 10).

Only the new line and carriage return characters are acceptable as record separators. No other record separator characters may be used.

6.7 End of file

The CESP system rejects files that do not conform to CESG end of file format. The following rules apply to end of file format:

• files must have a record type 999 record 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 CESP system accepts any single character as an EOF character following the record type 999 record
• no characters may follow the EOF character

6.8 File processing notes

The CESP transaction processing design supports the following file processing features.

A physical file may include records relating to the following:

• a trustee and 1 or more promoters (if the sender is the trustee)
• a single promoter (if a promoter or other agent is acting on behalf of a trustee)

Physical files are rejected if 1 of the following conditions applies:

• the CESP system cannot read either the file or the header record
• the header record contains invalid data, is missing, or appears more than once
• a duplicate header (the same promoter BN + date sent + file number) is already recorded in the CESP system
• the data version number is incorrect
• the filename does not match header record
• the trailer record contains invalid data, is missing, or appears more than once
• the sender BN is not authorised to send files
• the record count in trailer record is incorrect
• the filename does not follow the naming convention
• the header record is not the first record in the file
• the date sent in the file name or the header contains a date later than the current date

In all other cases the incoming file records are read into the CESP system. Transactions are validated and incomplete or invalid transactions reported back to the sender, along with appropriate error codes.

Transactions are processed during the reporting periods defined by CESP operations. All transactions with a transaction date on or before the reporting period end dates are processed during that period unless the transaction date is more than 3 years earlier than the processing date. In this instance the transaction will be processed but no grant or bond will be awarded.

Files are processed during the reporting periods as outlined in Data Interface Operations and Connectivity. All files with the same sender BN are processed in date-sent order. If the date sent is the same for more than 1 file in a reporting period, the files are processed by file number.

6.9 Record table terms

The following terms and abbreviations are used in the record format tables in section 3.

6.10 File naming standards

The physical naming of files is described as follows:

• to CESP: File type + sender BN +date sent + sender file number
• from CESP: File type + sender BN + date processed + CESG file number + extension

The filename must be 26 characters long, or the file is rejected.

The following definitions apply to the components of the file naming standard.

6.11 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.

6.12 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.

6.13 Transaction sequence

Transactions must be submitted in a logical sequence.

Once the contract has been established and registered and a beneficiary is processed by the CESP system, senders must report financial activities pertaining to that beneficiary and contract. The beneficiary does not have to pass SIR validation in order to be considered processed.

Record type 400 and 411 records may be sent in the same files as the record type 100 and 200, or in subsequent files.

7.1 Record type 001 - Header record

Purpose: to identify the source of a transaction file.

Requirements: none.

7.2 Record type 002 - Sub-header record (transaction processing report)

The record type 002 is included in the transaction processing report.

Purpose: the sub-header records supply reporting period information for each promoter in the transaction processing report.

Requirements: this record is generated by the CESP system and occurs as the second record type in the transaction processing report.

7.3 Record type 003 - Files processed record (transaction processing report)

The record type 003 is included in the transaction processing report.

Purpose: the files processed record gives the name of a production file sent by the sender that was processed by the CESP during the production run. 1 record is generated for each production file sent and processed.

Requirements: this record is generated by the CESP system and occurs as the third record type in the transaction processing report.

7.4 Record type 100 - Contract information

Record type 100 is used to provide contract information or request registration of a contract.

Purpose: to provide contract information necessary to request registration of a new contract or update an existing contract.

Requirements: corresponding records type 200 for a beneficiary and subscriber must be submitted to complete contract registration.

7.5 Record type 200 - Beneficiary/subscriber information

Record type 200 is used to submit beneficiary and subscriber information both for contract registration, and creating or updating beneficiary records.

Purpose: To provide the CESP system with :

1. beneficiary information, and
2. subscriber information

Requirements: subscriber SIN/BN must be provided for all contracts created after December 31, 1998.

7.6 Record type 400 - Financial transaction

Financial transaction, record type 400, is used to report financial activity on an RESP contract.

Requirements: a contract must be registered before any financial transactions are reported and the beneficiary record must be processed by the CESP system. The beneficiary does not have to pass SIR validation in order to be considered processed.

7.7 Record type 411 – BCTESG transaction

BCTESG transaction, record type 411, is used to report BCTESG activity on a RESP contract. There are 2 BCTESG transactions types reported: 40 – BCTESG request and 41 - Cancel BCTESG request.

Requirements: a contract must be registered before any financial transactions are reported and the beneficiary record must be processed by the CESP system. The beneficiary does not have to pass SIR validation in order to be considered processed.  

7.8 Record type 511 – PCG/spouse information transaction

Purpose: the 511-12 transaction can be used to provide PCG/spouse information not reported on the original 400-11 transaction, or to replace inaccurate PCG/spouse information reported on the original 400-11 transaction.

7.9 Record type 700 – Summary report transaction

Record type 700 is used to provide the CESP with the total assets in each RESP with a promoter. This record type is reported in its own file (see section 2.6), which has the same structure as the transaction file.

The summary report consists of:

• a header record – record type 001
• a series of summary reporting records - record type 700
• a trailer record – record type 999

Purpose: as part of its mandate, the CESP must report on its success in meeting its goals to various organisations within the federal government. Since the primary goal of the CESP is to encourage Canadians to save for their children’s post-secondary education, the growth in the total assets available to those beneficiaries for post-secondary education is a good measure of the success of the CESP.

7.10 Record type 800 - Transaction error report

Transaction error reports advise the sender that an error is present in a transaction record or that a record or file is rejected and must be corrected and resubmitted. If an error is detected, a type 800 transaction error record is created and added to the transaction error report.

The error report consists of:

• a header record - record type 001
• a series of error report records - record type 800
• a trailer record- record type 999

Purpose: Report transactions containing errors identified during processing, which allows the originators to correct and resubmit. Transaction errors are reported in report files referencing the promoter transaction identifier, along with the name of the field in error. The error report file is only sent by the CESP to senders. The file is always sent back to a sender whether or not there are errors.

The report records data format errors and business rule errors.

Requirements: based on CESP transaction records received.

7.11 Record type 850 - Severe error report

Severe error reports advise the sender that a severe error is present in a transaction, that the record is rejected and must be corrected and resubmitted.

The severe error report consists of:

• a header record - record type 001
• a series of error report records - record type 850
• a trailer record - record type 999

Purpose: Transactions containing severe errors that cannot have regular error messages applied to them are reported in the severe error report. These errors include the inability to identify the incoming record type or duplicate promoter transaction identifiers. This file reports an error type and contains the rest of the data record.

Requirements: based on CESP transaction records received.

7.12 Record types 900 and 911 – Transaction processing report

Each transaction processed by the CESP system is acknowledged by either a type 900 record a record type 911 for BCTESG transactions in the transaction processing report.

The transaction processing report consists of:

• a header record - record type 001
• 1 or more sub-header records - record type 002
• 1 or more file processed records - record type 003
• a series of transaction processing report records - record type 900
• a series of BCTESG transaction processing report records – record type 911
• a trailer record - record type 999

Purpose: to create a list of transaction details for each sender.

Requirements: none.

7.13 Record type 920 – SIN validation report

The SIN validation report consists of:

• a header record – record type 001
• a series of SIN validation report records – record type 920
• a trailer record – record type 999

Purpose: the record type 920 reports SIN validation activity to the sender.

Requirements: none.

7.14 Record type 950 - Contract registration report

Contract registration record, type 950, reports contracts which have submitted all information elements required to register a contract as of the current reporting period as well as contracts that have not yet met registration requirements during that specific reporting period. Please note that this report does not denote contracts as registered but rather contracts that are eligible to be registered by the CRA. The CRA will forward documentation to the promoter directly when informing them when contracts have been registered.

The contract registration report consists of:

• a header record – record type 001
• a series of contract registration report records – record type 950
• a trailer record – record type 999

Purpose: the record type 950 reports to the sender that a contract is registered.

Requirements: none.

7.15 Record type 960 – Referral report

Referral record, type 960, reports referral transactions to RESP promoters participating in the Education Savings Referral Service that are received by the CESP from Service Ontario.

The referral report consists of:

• a header record – record type 001
• a series of referral report records – record type 960
• a trailer record – record type 999

Purpose: the record type 960 reports a referral transaction to the RESP promoter.

Requirements: none.

7.16 Record type 999 - Trailer record (transaction control count)

Record type 999 is the last record in every file sent to or by the CESP.

Purpose: to provide the CESP and promoter systems with a control count of the number of records in a file.

Requirements: the record type 999 must be the last record in each file and contain an accurate control count or the file is rejected.

Transaction error codes

Transaction error codes are used to identify errors or discrepancies found in processing the various record types. Error codes are common across all transaction types, so that the same error generates the same code for all transaction record types.

Refusal reasons

Refusal reasons are used to tell why a contribution or request transaction which met all formatting rules did not receive any grant or bond payment. Refusal reasons are found in 2 locations in the 900 record type and 1 location in the 911 record type.

Severe error codes

Severe error reports advise the sender that a severe error is present in a transaction, that the record is rejected and must be corrected and resubmitted.

Province codes

Province codes are based on the Canada Post standard.

SIR validation

Senders must confirm with the subscribers that the basic information provided by the subscriber is exactly the same as the information recorded in the SIR. Confirmation can be made by referring to the beneficiary's SIN documentation.

The beneficiary SIN is electronically validated against the ESDC SIR database in the following manner:

• every beneficiary information transaction is validated with the ESDC SIR to ensure that the SIN, given name, surname, birth date and gender reported on the transaction correspond with SIR
• if SIR reports that the information provided in the transaction does not match the records in the SIR, then the CESP rejects the transaction and reports the error to the promoter in the error report
• the SIR check is performed as part of the validation of each beneficiary transaction received

In an attempt to raise the quality of our data with regards to the use of the SIN, please be advised that we will be systematically blocking all transactions submitted using known misused SINs.

In 2003, the SIR implemented new regulations to enhance SIN integrity resulting in a change in the CESP business process. 9 hundred series (900-series) SINs are assigned to people who are neither Canadian citizens nor permanent residents. Under the change, a 900-series SIN receives an expiry date correlated with the person’s authorized stay in Canada: 900-series SINs without an expiry date became invalid as of April 03, 2004. All SINs included on 200-03 transactions will be sent to SIR for validation including scrutiny for the existence of a ‘not useable’ flag. In addition to the increased scrutiny for new beneficiary transactions, all beneficiary SINs in the CESP system will be sent to SIR on a monthly basis for validation. A beneficiary SIN returned from SIR with a not useable flag will result in a not useable status in the CESP system and a suspension of grant/bond payments until the issue is resolved.

The SIR has asked the CESP to inform all SIN users that the misuse of a SIN number is a federal offence under the Employment Insurance (EI) legislation.