September 29, 2021 | 3 minutes read

When things go wrong: Investor reporting in securitisation transactions

Get in touch

Katie Hake

Associate Director

Co-Authors

Rebecca Wain

Get in touch

Katie Hake

Associate Director

Co-Authors

Rebecca Wain

With increased scrutiny from regulators around securitisation it is more important than ever that investor reports are accurate and reliable.

Transparency requirements for originators, sponsors and SSPEs

Under Article 7 of Regulation (EU) 2017/2402 (the Securitisation Regulation) the originator, sponsor and SPV on all securitisation transactions are required to make quarterly investor reports, or in the case of ABCP, monthly investor reports available to the noteholders and potential investors. These contain information about the credit quality and performance of underlying exposures, information on events which trigger changes in the priority of payments or replacement of counterparties, data on cashflows generated by the underlying exposures and information about the risk retained.

What mistakes can be made?

We have, in our role providing services to the securitisation industry, seen a number of areas in the reporting process contain errors which in some cases could have a major impact on the transaction at a cost to the structure and to the reputation of the parties involved.

No or limited quality assurance procedures in place.
Having insufficient procedures in place for reviewing the content of investor reports can lead to manual errors such as hardcoded values, formula not being dragged down, or input errors not being picked up.
Misalignment between calculations and transaction documentation.
We have seen situations where the calculations performed do not align with the definitions within the transaction documentation either due to misinterpretation of documentation or manual error resulting in reporting of inaccurate outputs.
Overcomplication of spreadsheets.
There is a positive correlation between the complexity of a spreadsheet and the likelihood of errors, in addition complex spreadsheets are also much harder to review, increasing the chances that an error may be overlooked. There are often several ways in which formula can be simplified and adding in error checks can help minimise the risk .
Miscommunication or lack of understanding of the specifics of the transaction structure. Errors can be overlooked due to a lack of understanding of the underlying data and/or transaction specifics by those who are putting together the report and therefore not being able to spot when something doesn’t look as it should.

What are the consequences?

Does it really matter? In short, yes, reporting errors can have notable consequences as the examples below demonstrate:

Error	Consequence	Impact on transaction
Errors in calculations or manual input errors	Triggers incorrectly being breached: We have seen a transaction incorrectly switch to paying noteholders sequentially rather than continuing to pay pro-rata. We have also seen the deferment of junior interest due to input errors overstating the amount on the principal deficiency ledgers.	Retrospective adjustments to investor reports and corrections to payments to noteholders. If the errors made have resulted in incorrect payments to noteholders then these will need to be corrected, which can be costly in both monetary terms and reputation and could potentially result in downgrades of the notes in more severe cases.
Manual errors	We often see manual errors where Excel models are used, such as duplicate formula, data entry errors or formulae linking to the wrong values. Where reports are rolled over month-to-month hardcoded input cells are often not updated, i.e FX rates or ratio changes.	Where errors have led to ineligible receivables being purchased, they have either been repurchased by the originator, or a waiver is obtained from the funder.
Misalignment between the methodology in the transaction documentation and the formulae in the models, particularly where amendments or restatements of the documentation are made	This is the area where we see the majority of errors, e.g default and delinquency ratios being understated. We are seeing an increase in reports being created using programming languages such as SQL, which reduces human error but we need to be mindful that amendments to documentation are correctly being updated in the model. Systems migrations are also an area where we see mistakes being made.	The consequences of a trigger breach are at the discretion of the funding parties, this can range from a warning to the originator/seller to improve performance, to the worst case scenario of a default event, leading to a financial penalty applied by the funder on the originator/seller or the removal of the facility.

Conclusion

Spending a small amount of extra time and effort in getting it right in the beginning can save a significant amount of time and money in the long run.

If you would like to discuss how we can help you with any of the above then please get in touch, contact details are below:

Katie Hake: khake@deloitte.co.uk Rebecca Wain: rwain@deloitte.co.uk