RBA Securitisations Industry Forum

The Current Weighted Average Life should be reported from the current Report Date of that tranche. Therefore the period of time already elapsed since the Issue Date to the current Report Date should be excluded from this calculation. Therefore if 2 years had already elapsed since the issuance of that tranche and a total WAL of 5.5 years is calculated for that tranche, ‘3.5’ should be reported in this field.

The new tranche should not be reported until it has been issued. However, once this tranche has been issued they must be reported whether or not they are currently eligible. Prior to making the submission, the IP will need to update the deal registration form with the details of the new tranche. This should be done at least one week prior to making the submission to allow for sufficient time for the information to be validated and the deal to be updated in the system. If the new issuance does not go ahead as expected, the details can quickly be amended. For tranches that have already been redeemed, these should be reported in full in the period ending with the redemption (with ‘0’ as the ending stated amount) and then no longer reported in subsequent periods.

These notes should still be reported for the period in which they are paid off (where the ending balances are reported as 0). In subsequent submissions these notes should not be included, however the RBA should also be informed that the notes have been fully redeemed when this occurs.

Where the fixed rate note does not have a soft bullet date, the final maturity date of that tranche should be reported in this field. Where the fixed rate note does have an associated soft bullet date, the final maturity date (hard bullet date) of that tranche at the end of all soft bullet dates (if there is more than one) should be reported in this field. The next applicable soft bullet date should be reported in the Soft Bullet Date field and updated with the subsequent soft bullet date every time that date is reached.

These notes will need to be reported as new tranches and the IP will be required to complete a form that outlines the modifications to the deal. The matured notes will then be deactivated and the new notes activated in the deal. The only time a new tranche should not be created is where the re-issued notes have an ISIN that is identical to the notes that were redeemed. In this case the same tranche needs to form part of the submission, updated with any changes to the terms of the tranche (e.g. the new face values, etc.).

The field needs to have sufficient information so that an informed reader can determine the legal basis of the offering without reference to an external document unless this reference document is publicly available and the full details of this reference document are clearly outlined in the response. For example, ‘REG-AB’ is acceptable as an informed reader should be able to access the source documents related to this regulation, while ‘Domestic’ or ‘Part 3.1 A’ are not acceptable responses. If there is a reference to the deal documentation then the source of this should be made clear in the field, i.e. ‘Part 3.1 A of the trust's Series Amendment Notice’. It should be noted that this field has a 100 character limit.

Scheduled Coupon is calculated by dividing the coupon rate (as a decimal) by the coupon payment frequency and multiplying this payment rate by the Stated Amount of the notes. Certain transactions may include tranches that only make references to the Invested Amounts of the notes instead even when there are charge-offs, the Invested Amount should be used where this is the case. Scheduled Principal is for bonds with a controlled amortisation feature that amortises the bond at a pre-defined rate. This amortisation schedule will determine how much principal is paid down from the bond on each payment date and this value should be reported in this field.

All relevant nodes will need to be reported on a monthly basis. Loan and pool information is expected to be updated every month. Tranche data should reflect the distribution cycle of the trust. For a quarterly or semi-annual paying security, a 0 should be reported for any values in non-distribution months which would otherwise be applicable in a distribution month. For example, the Coupon Distribution field should be recorded as 0 when no coupon payment has occurred in that month. On the other hand, fields that are not applicable to the deal or tranche should be reported as ND5 (e.g. Scheduled Principal where the tranche is not a controlled amortisation bond). Deal level fields should be updated monthly for those fields that are required to be updated on a monthly basis (e.g. Report Date) or which are based on loan level data (e.g. Loans Originated). Deal level fields not related to loan data can be updated in line with distributions (e.g. Trigger State and Key Role Fee).

All seven role entities (and potentially any ‘Other’ role entities included) have a key role field associated with them and any fees paid to these entities should be reported in these fields. So if a fee is paid to the Responsible Party for providing a service to the trust then this should also be reported in the Key Role Fee Currency and Key Role Fee fields in that block.

Fields related to the trust's settlement date should be provided as at the original settlement date of the transaction regardless of any collateral changes that have occurred post this date. So even if the pool has topped-up and the face value of notes outstanding or the mortgage pool balance have increased materially over time, values should be reported as at the original settlement date in these fields.

Tranche level data should always be reported in the currency in which it is denominated. So for a USD denominated tranche, the tranche fields should all be reported in USD terms. No exchange rate conversions should be applied to these fields. A currency field is usually included in that block to define what currency the values are denominated in (in this case it would be the Tranche Currency field).

The three step-up related fields should be included even if the step-up already occurred in the past. In the case of a single step-up, the Step-up Date (RS052) would equal the date on which the coupon previously stepped up and the Step-up Margin (RS051) would be identical to the Coupon Margin (RS050) field.

In the case where there are multiple (or a schedule of) step-up's, then RS051 and RS052 should be replaced each time a step-up occurs with the information from the next stage. For example, if the original margin for the security was 80bps and the coupon stepped up (to 10501-28) and there was another step-up (to 130bps on 2015-01-28) then ‘80’ and ‘2014-01-28’ should be u bps on the 2014-sed for RS051 and RS052 respectively up until the first step-up date after which ‘130’ and ‘2015-01-28’ should be used afterwards until maturity assuming that no further step-ups are set to occur.

Yes. If even one tranche of a transaction is repo eligible, a security template must be completed for every active tranche in the transaction, regardless of whether that particular tranche is eligible or not.

Where additional or new notes are to be issued from an existing repo-eligible trust to fund the purchase of new loans, the RBA has to be notified of the upcoming transaction prior to its execution. The full suite of templates reflecting the new note balances and the entire collateral pool should be submitted as soon as possible after the transaction has been executed.

In the period that the tranche is redeemed, all fields for the tranche should be reported (including, for example, ending stated amount reported as 0.00). In subsequent reporting periods, no further reporting of the tranche is required. In addition to the reporting requirement, information providers will likely be required to contact the RBA to notify that a tranche has been redeemed. The industry will be advised on the exact arrangements for this in due course.