Tania Fago, senior product manager at Quantifi, comments on how the ABS market could benefit from independent data description of waterfalls under the SEC's new disclosure proposals
On 7 April 2010 the SEC proposed rules to amend the offering process, as well as tighten the disclosure and reporting requirements for ABS. The proposed changes are designed to increase transparency and thereby improve investors' understanding of these financial products, which have traditionally been more opaque.
Specifically, the SEC proposals would:
• require the filing of a computer programme that gives effect to the waterfall
• require the filing of tagged computer-readable, standardised loan-level information
• provide investors with more time to consider transaction-specific information
• repeal the investment grade ratings criterion for ABS shelf-eligibility
• increase transparency in the private structured finance market
• make other revisions to the regulation of ABS.
This article examines the SEC proposal to require the 'Filing of a Computer Program That Gives Effect to the Waterfall Provision of the Transaction'. The waterfall dictates how the cash collections, losses and administrative expenses are distributed to the investors in the various tranches of the ABS. This computer programme would be in addition to the filing of a prospectus for an ABS transaction, which currently includes only a narrative description of the waterfall.
In general, Quantifi is in agreement with the following two points, which we consider to be the ultimate goals of the SEC proposal regarding tightened waterfall disclosure:
(i) full transparency of the waterfall
(ii) availability of sophisticated tools to undertake detailed and relevant risk analysis.
Beyond these general goals, the SEC's proposal to require the disclosure of a Python computer programme that demonstrates the effect of the priority of payments 'waterfall' is generating significant discussion among a number of market participants - including issuers, investors, software vendors and financial engineers.
While some of the attention is centred on how the Python language compares to other languages, such as XML, Perl, Java, C-Sharp, etc., Quantifi is focused on the bigger picture. We suggest that a solution separating the description of the waterfall from the programme that generates the cashflow of the waterfall would more appropriately achieve full transparency and availability of sophisticated solutions.
Although we think separation is more important than the ultimate language chosen, for illustrative purposes, we will assume an XML extension is used for the waterfall description and Python is used to demonstrate the execution of the waterfall. We believe that there are practical and useful applications to these complementary technologies and that the marketplace could benefit if the SEC considered disclosure where both forms were required.
In order to disclose both Python and XML most usefully, we propose that the concepts of (i) the description of the waterfall and (ii) the programme that demonstrates the execution (or effect) of the waterfall be separated. The Python programme would operate on the XML data description. We believe that such a separation best achieves the goals of full transparency and availability of sophisticated tools.
XML is a logical language to use for reporting the data description of the waterfall because it provides an independent description of the waterfall, which will ensure that the waterfall disclosures will not only remain relevant over time but also facilitate implementation in robust risk management techniques and systems. Python, among other languages, is an attractive language to use for a programme that operates on the waterfall's data description because it could be executed directly.
XML data disclosure will enable more sophisticated analysis, including advanced risk management and hedging practices. These methods could be accomplished via the integration of the XML data description into more powerful programmes. Such programmes would have a greater computing capacity and be able to more easily evolve with market practices.
A waterfall execution programme that attempts to capture all of the important risk management factors today may become irrelevant in the future or cause market participants to ignore critical factors that were not foreseen or incorporated in the original programme. For example, during times of prosperity, it may have been difficult to foresee the increased focus on triple-C buckets or discounted asset purchases that occurred in the more recent tumultuous times.
However, such an execution programme could still be useful if the scope were limited to a small set of functions, such as trade pricing/agreement between two parties or simple waterfall verification/analysis. Limiting the scope of the programme will also help to lower the effort required to issue a new security.
In order to facilitate further discussion, we have highlighted several advantages and considerations of a waterfall specification in executable Python versus XML extension.
Python
A Python script, as proposed, will attempt to encapsulate: (i) description of the waterfall structure and (ii) implementation of the waterfall (or in other words, execution of the operations outlined in the data description).
Advantages:
• It will be able to represent any waterfall structure
• Once written, Python code would be executable directly, as it would not need to be amended to be compatible with the computer. This is a key advantage of an open source programming environment
• Potentially less work upfront because the programme will likely be done on a deal-by-deal basis rather than identifying common waterfall structures upfront.
Considerations:
• A Python specification will likely be difficult to inspect, verify or understand because of the complexity inherent in modelling the execution of complex waterfalls. This complexity will, in practice, cause a Python specification to be less transparent and closer to a 'black box' system
• Specifying both the description of the waterfall and implementation of the operations will restrict the ability to do more detailed analysis and risk management (note that specifiying the operation of the waterfall is limiting, regardless of what programming language is chosen)
• Python specifications will likely end up being a 'best effort' black box and potentially something that is not reliable enough to incorporate into risk management systems
• Vendors that develop software will have difficulty incorporating the Python script from a technology and legal perspective, as they will be delivering software that depends on waterfall executables for which they do not own the IP, cannot verify, be responsible for and warranty in any way
• Software typically contains bugs. Each new deal is likely to incorporate bugs that will need to be managed.
XML extension
XML extensions are a flexible way to create common information formats to share data description of the waterfall.
Advantages:
• Very straightforward to process, easily portable and flexible enough to describe all necessary waterfall structures
• Specifying only the description of the waterfall gives users flexibility through appropriate programmes acting on it to perform any detailed analysis and testing that is required by the marketplace. Additionally, as these requirements change over time, the programmes may be independently changed without affecting the waterfall descriptions disclosed at issuance
• Transparent because it is: (i) likely to be simpler and (ii) programmes operating on the waterfall will provide outputs, logging, etc. that most closely matches the user's requirements. Risk management techniques will be more easily developed and applied as the programmes acting on the waterfall descriptions will be designed to work with and within the necessary risk management systems. The programmes can change easily as these risk management systems and techniques change.
• Preferential for vendors from both a technology and legal perspective because they will own the IP for the implementation of the waterfall
• A SIFMA XML representation of cash CDO trustee report details already exists, as it was proposed back in the 2005-2007 timeframe
• The proposal and effort previously put into the SIFMA XML representation could serve as the preliminary point for the SEC proposal, with additional time spent factoring in the constructs to illustrate the waterfall - something that was omitted from the SIFMA work.
Considerations:
• A significant amount of work is required upfront relating to all the tagging of terms and data, including testing and validation
• It is able to represent most waterfalls, in particular simpler ones, but not all waterfalls. However, in the foreseeable future there will be a finite number (10-15) of waterfalls, which will be simple and therefore easily supported by a language such as XML. Also, the versatility of XML will over time enable it to model any XML structure
• Bugs may exist in the representation of each new waterfall structure; however, these would be resolved at the software vendor level for each limited number of waterfall type rather than for each new deal
• An external programme is required to perform analysis. We believe that this omission is actually an advantage, but it is useful to point out that users will be unable to perform analysis based solely on the items in the disclosure.
Quantifi is well positioned to respond quickly and effectively to whichever language and approach is adopted by the SEC. However, as highlighted above, we believe market participants will benefit most from an independent data description of the waterfall. Recognising the separation between the data description and the programme executing on it will greatly improve the effectiveness of these disclosure requirements, especially as markets, methodologies and models continue to evolve.
Quantifi has also been working closely with the Risk Management Association's Securitization Risk Roundtable (SSR) to respond to the SEC proposal. The roundtable has been focusing its efforts on responding to the proposed waterfall disclosure requirements. SRR is an organisation that identifies key risk issues facing the securitisation industry and recommends actions to regain marketplace confidence.
