Office of the Superintendent of Financial Institutions
OSFI has specified a return for the Basel Capital Adequacy Reporting (BCAR) data call. This return must be submitted to OSFI through the new Tri-Agency Database System called RRS (Regulatory Reporting System). The data definitions for the return are found in  &  and this document highlights the technical file layout and format for that file. Note that the technical specification document should serve as the primary guideline whenever it is not completely ‘in-synch’ with the data definitions document .
 OSFI, “BCAR External_Template.xls”, Microsoft Excel Spreadsheet, Unclassified OSFI Publication.
 OSFI, “BCAR Technical Specification – Dimensional Data Definition”, Microsoft Excel Spreadsheet, Unclassified OSFI Publication.
Note that the MS Word version of this document (available in RRS) and Dimensional Data Definition document  should be in the same folder for the links to work.
In this section, we explain a number of concepts and terms related to the way that Return data is organized within a Return data file. We begin with a description of how to read the new BCAR template then move to dimensions and measurement records. Then these concepts are related to record types, which specify the set of fixed length measurement records that you will provide in your Return data file.
In the earlier versions of the BCAR External Template each cell had a unique designated datapoint address (DPA). This value was used to represent the single location or cell where a value was required. BCAR had 2 categories of DPA codes, 4 digit and 8 digit. The 4 digit DPAs represent line-items without any additional dimensionality. An example is DPA 1001 which exists on Schedule 1 and has a label of Tier 1 Ratio (%). The representation of these 4 digit DPAs is unchanged in the new definition of BCAR. Each 8 digit DPAs represents a combination of dimensions with a single measure. The concept of these 8 digit datapoints has been replaced with the concept of dimensions and measures. In the first example below we see how a datapoint is represented in an older version’s template.
This example is for Schedule 9 from 2016 Final Sample Return which is currently available on the OSFI website. Note that each cell has a unique datapoint.
In the new set of schedules and template the same datapoint would be represented as a cross section of dimension codes and a measure.
In this case the indicated cell would be a combination of the following dimensions and measure code.
Gross Exposure (credit-equiv. amount for off B/S) before CRM (M13)
Approach Type (APPROACH_TYPE) = No Approach Type(299)
Probability of Default Band (PD) =Not Applicable (1499)
Double Default Framework (DD) = No Double Default (301),
Equity Characteristics (EQUITY_TYPE) = Not Applicable (1099)
Default / Dilution Risk (Risk_Type) = Not Applicable (1199)
Variable Dimension Codes:
BCAR Exposure Classes (EXP_CL) = Total Retail residential mortgages (108)
Exposure Type (Exp_Type) = Drawn (501)
Risk Weight (Risk_Weight) = 0% (701)
Note: the datapoint used in this example is no longer required after Q4 2016.
A dimension is a list of business categories that are grouped under a single business concept. For example, we have the BCAR Exposure Classes dimension shown below. The 19 categories (or dimension values, as they are often called) are assigned, as we see in the table below.
BCAR Exposure Classes
The table shows dimension values. Each value has a key and label. In addition, a dimension can be hierarchical. BCAR Exposure Classes is a hierarchical dimension whereby several values roll-up under a higher level value. This is represented by the parent key column. Hierarchies are typically validated using aggregation rules. Rule types are described in the Global document. This document reference will be added later to the bibliography.
List of Dimensions
List of Enumerations
Measures are specific addresses or cells that represent a value that needs to be reported.
Typically a measure will be a unique cell in valid combination of dimension codes.
In this example from Schedule 9 in “BCAR External_Templates.xls”  the measure for the indicated cell is: Gross Exposure (credit-equiv. amount for off B/S) before CRM (M13)
List of Measures
OSFI is responsible for collecting and evaluating several general categories of information. Each information category is defined by a set of dimensions and measures.
Taking an example from Schedule 5 of BCAR which represents Standardized Approach – Credit Risk-Weighted Assets - For Banking Book – Total Corporate:
In another example from Schedule 22B of BCAR which represents IRB Approach – Credit Risk-Weighted Assets – For Banking Book - Corporate:
An invalid combination otherwise known as a hole is an instance where a value is not required. Currently this applies to BCAR returns only, although in the future it may apply other returns as well. A hole is identified by a grey cell as in this example.
Measure Holes – a measure hole is like the example provided above , it is a single cell where a value is not required.
Dimensional Holes – A Dimensional Hole is a series of measure holes that may or may not appear on the table. It is often represented by its absence. In the example below record Type 005 is defined as having multiple Exposure Types (EXP_TYPE) yet only three are displayed for data entry:
Exposure Types (EXP_TYPE) = Drawn (501)
Exposure Types (EXP_TYPE) = Undrawn commitment (502)
Exposure Types (EXP_TYPE) = Other off-balance sheet (505).
There are several exposure types that are not required in this schedule:
Exposure Type (EXP_TYPE) = Repo-Style Transaction (503)
Since there are no values required across the full range of all the measures for this Exposure Type it is not even displayed on the schedule. Had it been displayed all its values would have been greyed out. This is a dimensional hole.
Note that Exposure Type (EXP_TYPE) = Repo-Style Transaction (503) is absent from Schedule 9 – Record Type 005 although it is on the list of allowed values.
List of Invalid Combinations (Holes)
Beneath each record type grid is a link that opens an Excel sheet, “BCAR Technical Specification – Dimensional Data Definition.xls”,  that displays the list of measure and dimensional holes.
As highlighted in the example below, document “BCAR Technical Specification – Dimensional Data Definition.xls”  lists all the possible cross sections of dimension and measure for each record type.
Where the value is 0 that combination is not required to be reported or in other word is a hole. The value 1 indicates that it is a valid combination and a value can be reported.
When multiple dimension codes are displayed then the accompanying value refers to the full range of those dimension codes. This is what is referred to as a dimensional hole
Example 1 – Measure Hole
Example 2 Dimensional Hole
Measure: all measures
The following sections describe the BCAR Return extract file layout required by RRS.
The data file will have the naming convention of FI_BA_MMYYYY.DAT, where FI represents the Institution ID (provided by OSFI), BA is a fixed string representing the two characters identifying the code for this return, MM represents the month and YYYY represents the year of the reporting date of information.
The data file will be a variable length text file – the length of the line will depend on the specific Record Type –and end with a carriage return (CR) and line feed (LF) as record delimiters.
The first row of the extract file must be a header record (“000”). Apart from the header, all the other records may be in any order. These records represent the values collected for each Record Type.
Each line of your Return data file is for a specific Record Type. Valid Record Types that will be reported are shown in the table below. RRS must be able to identify the type of record in order to parse it into its constituent fields. To facilitate this process, every record begins with a three-character “Record Type” identifier. The specific record structure for each Record Type is specified later in this document.
The Dimensions and their key value ranges required by this Return are shown below. Links for each dimension will provide the list of key values.
This section described the record structure for each Record Type.
The record structure is defined using a table with 6 fields. Each field is described below:
This is the RRS identifier for the dimension or measure.
This is the Name of the dimension or measure.
This provides additional information on how the field should be populated. In some cases this will be a fixed value and in others there will be a range of allowed values that should be used.
This is the fixed character position in the data file record where the value must start.
This is the length of the reported value. The reported value must be right justified. Where the reported value does not fill the entire available length, the characters on the left must be padded with blank or zero characters. Where there is no value to report the entire length must be padded with blank characters.
This field indicates whether the field is a dimension or a measure. Y indicates a dimension.
It should be noted, that no line numbers have been specified for any of the record type definitions. This is a change from how current dimensional record structures are defined as RRS has no use for this information. However, no errors will be thrown if the line number is provided at the end of each record.
The header record is a quality control mechanism that uniquely identifies each file sent to OSFI (i.e. who sent the file, the reporting date, the file name, etc). The information contained in the header field is checked against the file name and the actual details of the file to ensure that the file received by OSFI has not been corrupted.
The record structure layout of the header record is detailed below:
The standardized approach to calculating credit risk-weighted assets is outlined in Chapter 3 of the guideline. All data for exposures reported under the standardized approach are captured here with the exception of reverse mortgage data from schedule 9 which is captured under record types 040 and 045 and standardized securitization data which is captured under Conventional DPAs (record type 998). The record structure layout for this information category is detailed as follows.
Record type 010 captures data for exposures reported under the general IRB approach described in Chapter 6 of the guideline, including information relating to any LGD adjustments to reflect guarantees. Exposures that do not follow the PD, EAD, LGD approach are captured under other record types, including an item on purchased receivables, an item on default/dilution risk, specialized lending, PD/LGD approach to equity, IRB equity and securitization, respectively captured under record types 030, 035, 015, 025, 998 and 998. The record structure layout for this information category is detailed as follows.
Specialized lending is a subclass of Corporate for which the reporting institution does not meet the requirements for estimating PDs and cannot use the risk-weight formulas. In these cases, it must use a Supervisory Slotting approach to calculate risk-weighted assets. The record structure layout for this information category is detailed as follows.
The PD/LGD approach for equity exposures is only available for non-tier 1 perpetual preferred shares without a redeemable feature and perpetual preferred shares with a redeemable feature at the issuer’s option. The methodology for calculating risk-weighted assets under the PD/LGD approach is described in section 6.5.1(ii). The record structure layout for this information category is detailed as follows.
Within the corporate and retail exposure classes, eligible purchased receivables are given unique treatment, whereby risk-weighted assets are calculated separately for default and for dilution risk. Additional data relating to purchased receivables under this treatment are captured under ‘Purchased Receivable EL and RWA’ (Record type 035). The record structure layout for this information category is detailed as follows.
List of Invalid Combinations (Holes)
Measures relating to eligible purchased receivables qualifying for special treatment are captured in this record type as well as in Purchased Receivables (record type 030). The record structure layout for this information category is detailed as follows.
Reverse mortgages are given special capital treatment set out in the Advisory on the Capital Treatment of Reverse Mortgages. In addition to the data captured here, reverse mortgages must also be included under the Standardized approach (record type 005), under Total Retail residential mortgages (exposure class 108). Additional data may also be captured under Reverse Mortgages Deducted from Capital (record type 045). The record structure layout for this information category is detailed as follows.
Reverse Mortgages to be deducted from capital as set out in the Advisory on the Capital Treatment of Reverse Mortgages are reported here as well as under deductions from capital and are additionally assigned a 0% risk weight.
Institutions with operations outside Canada will look at the geographic location of their private sector credit exposures and calculate their institution-specific countercyclical capital buffer requirement as a weighted average of the requirements that are being applied in jurisdictions to which they have credit exposures.
Data not captured under the other record types are captured here. A value must be provided for every DPA code where there is one available. The record structure layout for this information category is detailed as follows.
Changes in version 2.0
These entries highlight changes made since the last release of this document. This log has been written for the technical audience who is already familiar with the previous release of this document and needs to know what changes have been made to it. Readers should have Version 1.0 of this document on hand when reviewing this change log.
Those not already working with Version 1.0 of this Technical Specification Document do not need to use this change log.
Section 1.1 - Replaced 3 excel spreadsheets with one single spreadsheet ‘BCAR Technical Specification – dimensional data definition’
Section 3 and 4 –
Section 4.3 –
Section 4.4 – Added Dimension Type ‘Country’
Section 4.5 –
Changes in version 3.0
These entries highlight changes made since the last release of this document. This log has been written for the technical audience who is already familiar with the previous release of this document and needs to know what changes have been made to it. Readers should have Version 2.0 of this document on hand when reviewing this change log.
Those not already working with Version 2.0 of this Technical Specification Document do not need to use this change log.