Reporting Guidelines

Reporting Guidelines

The Reserve Bank of Australia’s (RBA) eligibility criteria for asset backed securities (including RMBS, CMBS and other ABS) requires Information Providers to submit a single XML file (no zip files) per deal, per month (regardless of the coupon payment frequency) containing all required data (loan level, security level, transaction level, pool level, cash flow waterfall model and related data). The relevant securitisation data must also be made available to the public, as outlined below.

Who Provides the Information?

The reporting can be done by whichever entity in the relevant securitisation structure is best placed to do the reporting. It is recognised that this may be an originator or servicer, and not the issuer.

Reporting Frequency and Due Date

Effective 1 March 2018, reporting through the Securitisation System will be due on the monthly anniversary of the distribution date.

Securities that lose eligibility due to late reporting will remain ineligible until all outstanding submissions related to that security have been made and a subsequent submission has been completed successfully by the due date. As a result, missing the reporting deadline will result in securities being ineligible for repo with the Reserve Bank for at least a month and possibly longer if a submitter misses the deadline for more than one consecutive month.

For Trusts with replenishable pools, the RBA will reserve the right to request out-of-cycle reporting templates.

No Data Policy

The RBA has included ‘No Data’ (ND) options in each data template, which are to be used whenever a particular data field cannot be submitted in accordance with the template. All data fields are mandatory and must include either a valid response or a valid ND code; fields should never be left blank.

From 31 December 2015, ND1, ND5 or ND6 will be the only permitted ‘No Data’ replies for any missing data. The Bank reserves the right to remove the security from the repo-eligibility list, if, from 30 June 2015, a large number of data fields feature ND1 replies.

Availability to Permitted Users

To meet the Bank’s data availability requirement, the data must be made available to permitted users free of charge either on a secure website managed by or on behalf of the Information Provider, or through a data warehouse with secure access and expertise in handling the new reporting requirements. Permitted users are those parties interested in asset-backed securities for investment purposes or for professional or academic research purposes. Only the most recent reports provided to the Bank need to be made available.

The Cash Flow Waterfall (CFW) Model and related data should be made publicly available in XLSM (Excel macro-enabled workbook file) format, with all of its contents (worksheets, cells, Visual Basic for Applications modules etc.) visible and transparent (as specified in the Cash Flow Waterfall Reporting Template). All other data (non-CFW related) should be made available in a usable format (for example, csv, xlsx or xlsm).

Internal securitisations are not exempt from the data availability requirement. However, issuers will be able to make available to permitted users a pool level summary of the loan level information, rather than making available loan-level information.

The Bank does not intend to require, coordinate or fund the establishment of a central data repository for the reported data. The Bank is currently considering what steps might be taken to facilitate directing appropriate users to the relevant providers or locations of the data. Any relevant advice will be provided in due course. Please ensure that you have signed up to the RSS feed.

Data Availability, Privacy and Liability

Loan level data

Information Providers should restrict access to the loan-level data to those users who require it to evaluate ABS for investment purposes or for professional or academic research purposes.

The Bank expects that information providers will adopt a process to determine whether to approve a request by an entity for access to loan-level data taking into consideration the proposed recipient’s status in relation to securitisation transactions, ability to comply with an agreement with the information provider that limits the purpose for which the data may be used, and implementation of security controls to prevent unauthorised access to, or loss of, the loan-level data.

The Bank supports and encourages the implementation of appropriate safeguards by information providers in order to manage any privacy risks associated with their disclosure of loan-level information to permitted users, but expects safeguards to be proportionate to the relevant privacy risks.

For further information, see RBA Securitisation Implementation Notice – 28 October 2015

The RBA has amended its reporting requirements in order to enhance borrower privacy protection. In particular, the RBA does not require Information Providers to provide certain details in the following loan-level data fields in the publicly reported RMBS loan-level template:

  • The last three digits of the property’s postcode (RL062). However, the property’s Australian Bureau of Statistics Statistical Area (Level 4) (SA4) (RL094) should be reported in the publicly reported loan-level template. This field should also be reported in the loan-level template reported to the Bank.
  • Nine of the date-related loan-level data fields can be reported in the publicly reported loan-level template in quarterly calendar time. In particular, information providers should report the calendar quarter instead of the exact date in origination date settlement date (RL022), maturity date (RL028), interest only expiry date (RL047), current rate expiry date (RL048), date of foreclosure (RL052), and most recent property valuation date (RL068). Similarly, information providers can report in the publicly reported loan-level template the number of quarters instead of the number of months for the loan term (RL025), remaining term (RL026) and seasoning (RL027). The details on the reporting of each of these loan-level data fields are detailed in each fields’ Guidance Notes within the RMBS Consolidated Reporting Guidance. All loan-level data fields should be reported to the RBA in full.
  • A number of other fields will not be reported on a loan-level basis owing to the sensitivity of the data. However, Information Providers should publicly report a pool-level postcode summary of these fields (see Postcode Pool-level Data Template [XLS]) as well as a Detailed Pool Report (see Pool Detail Report [XLSX]). These tables should not be reported to the Bank.
Internal securitisations

Internal securitisations are not exempt from the data availability requirement. However, issuers will be able to make available to permitted users a pool level summary of the loan level information, rather than making available loan-level information. This reflects the fact that these securities are not marketed. Pool-level information obviates the need for issuers to have in place permitted user agreements for access to loan-level information on these securities which could result in selective access to potentially market sensitive data. See Pool Detail Report [XLSX] and Pool Summary Report [XLSX] for an example template. Loan-level data still needs to be reported to the RBA.

Marketed securitisations

For marketed securities, issuers will be able to redact a number of loan-level fields in the information they provide to permitted users. The fields are as follows:

- RL018 – Offset account balance
- RL046 – Restructuring arrangement
- RL049 – Account status- RL050 – Default balance
- RL058 – Claim submitted to LMI
- RL059 – Claim paid by LMI
- RL060 – Claim denied by LMI
- RL061 – Claim pending with LMI
- RL082 – Bankruptcy flag
- RL086 – Credit score
- RL090 – Income
- RL092 – Non-primary borrower income

Please be aware that this information should be presented at a pool level.

Information Providers may include reasonable disclaimers regarding data accuracy, however they should not be couched in a way that limits substantially the value of the information being provided and should not reduce, or purport to reduce, the representations and warranties that investors are entitled to rely on under the relevant transaction documents.

Grandfathering of Certain RMBS, CMBS and other ABS

The RBA will make certain exemptions to the reporting requirement for legacy transactions where, at 30 June 2015 and subsequently, the aggregate amount of outstanding AAA-rated AUD-denominated tranches in the transaction is less than $100 million. For these deals the cash flow waterfall will not be required for any asset class; for RMBS and CMBS loan-level reporting is exempt; while for Other ABS pool-level stratifications will be exempt (corresponding with the following nodes in the XSD: Zero Prepayment Scheduled Pool Balances; Issue Date Stratifications of Data Measured at Contract Origination; Issue Date Stratification; Issue Date Other Jurisdictions Geographical Location; Report Date Stratification; and, Report Date Other Jurisdiction Write Offs).

Furthermore, self-securitised RMBS will also be exempted from the requirement where the authorised deposit-taking institution (ADI) is subject to APRA’s minimum liquidity holdings (MLH) framework and the aggregate size of the AAA-rated AUD-denominated tranches in the transaction is less than $100 million.

Submission and Validation

All data for each transaction must be submitted together at the same time to the RBA. Once submitted, the data will be quality tested and data that does not meet the RBA’s validation standards will not be accepted.

For further information about the Securitisation System Validations, refer to Support Material.

Securitisation System User Agreement

The Securitisation System User Agreement is an agreement between the Reserve Bank and each Information Provider that is entered into via the Securitisation System (which also takes effect as an agreement between the Reserve Bank and each natural person that uses the Securitisation System on behalf of an Information Provider). The Agreement includes undertakings by the Reserve Bank regarding the confidentiality of the information provided via the Securitisation System. It also includes undertakings by the Information Provider regarding privacy and data quality.

The Securitisation System User Agreement was last updated in March 2019 by the Reserve Bank and included the following changes:

  • The Reserve Bank can use securitisations data to perform any of its functions or exercise any of its powers under any law. (Clause 1.2(b)(i), which already permits use under the Reserve Bank Act 1959 (Cth))
  • The Reserve Bank can disclose statistical information or analysis derived from the securitisations data, provided that such statistical information or analysis does not disclose information about any identifiable individual or entity. (Clause 1.2(b)(v), which already permitted this for the purpose of ‘publication’, has been amended)
  • The Reserve Bank can liaise directly with certain parties to the relevant securitisation (including the original source of the securitisations data) in addition to the Information Provider in order to, among other things, address questions or issues arising from the data that has been submitted. This now includes instances where the Information Provider (i.e. the entity that submits securitisations data to the RBA) is a different entity from the entity that is the original source of the data. (Clause 1.2(b)(vi))
  • The parties now agree the agreement constitutes the entire agreement between the parties in connection with its subject matter. (Clause 7.1(b))

The User Agreement is available via the Securitisation System. The User Agreement takes effect between the Reserve Bank, the User and the relevant Information Provider when the User clicks ‘I agree’ to the User Agreement. A User is prompted to click ‘I agree’ the very first time they login to the Securitisation System after the User Agreement has been updated. Once the latest version of the User Agreement has been agreed to by a User, they will not be prompted again to agree to the User Agreement on subsequent logins (unless and until the User Agreement is further revised).