SEC Proposals on ABS: waterfall computer program
A number of the SEC Proposals on Asset-Backed Securities have attracted much criticism but perhaps none more so than the proposed requirement for issuers to file on EDGAR, as part of an ABS offering, a waterfall computer program of the contractual cash flow provisions of the securities being offered. If enacted, it is not unreasonable to posit that this single aspect of the proposals might be sufficient to drive issuers out of the public market.
The proposed rule’s policy objective is to provide to potential investors the wherewithal to conduct their own evaluation of the securities so that they can make an informed decision on whether to participate in the offering without undue dependence on the opinions of credit rating agencies. The underlying premise here appears to be that investors’ lack of understanding of complicated securitization structures resulted in poor investment decisions in the past.
Contrary to the SEC’s underlying premise, that “issuers’ already produce such a code to structure the ABS deal”, this is apparently not the case and the overwhelming consensus seems to be that to build such a model would be enormously complex and expensive.
Some of the problems cited are the following:
- While existing cash flow models have been constructed and utilized by underwriters and third-party vendors, issuers have generally not done so.
- The existing programs do not generally (if at all) use the Python open-source programming language mandated by the SEC.
- These models allocate cash and losses on an aggregate basis and not on a loan level basis as required by the SEC proposal.
- It may not even be possible to build the type of program required by the SEC for master trust or co-ownership structures where there are unknowable variables related to other series of securities which share recourse to a common pool.
- The existing models do not meet the standards of precision that the SEC specifies but rely on various simplifications since they are designed to enable investors to understand how cash flows can be expected to perform generally in different scenarios. They are not designed to reflect every kind of input and output related to the structure, no matter how immaterial, and they may not be able to model all structures and scenarios or address unknown variables.
- The issuer would need to engage significant resources in order to maintain and update the program and provide instructions on use and customer service
More than one commentator has observed that this proposal would in effect require issuers to become software developers and distributors, a role for which they are likely to be particularly unsuited. Rather it would seem to be more likely that issuers would turn to third-party service providers.
The waterfall computer program proposal also raises significant legal issues. The proposal requires that the program be filed with, and incorporated by reference into, an issuer’s registration statement. It is unclear to what extent this would mean that the design features and the output of the computer program would be treated as issuer “statements” attracting the same liability as all other statements. Various nightmarish scenarios can be imagined. For instance, if a programming error caused the program to generate faulty results would this be a misstatement? If an investor could not figure out how to run the program, would the issuer be liable for a material omission?
Perhaps the most fundamental issue of all is raised by the requirement that the “code must provide the user with the ability to programmatically input the user’s own assumptions regarding the future performance and cash flows from the pool assets”. But any such code, like any credit assessment model, must itself invariably be predicated upon certain assumptions, based on a subjective assessment of the remoteness of various risks, involving the selection of variables that are deemed sufficiently material to merit modelling. To build an open-ended model which is able to anticipate assumptions of others and quantify all risks no matter how remote may not even be possible. Yet one is left to wonder whether the failure to do so would be a material omission under the SEC proposals.
In the past modeling was the domain of those with experience in the area such as underwriters and credit agencies. To shift responsibility for this to issuers who have no expertise in the area and, at the same time, to impose a strict liability regime with respect to outputs generated not by the issuer but by investors is well beyond what is fair and reasonable in the context of an ABS issue. Given the complexity of the required programs, the necessity for reliance on third parties and the uncertain liability issues, it is unclear how issuers (or underwriters for that matter) would ever be able to get sufficiently comfortable with their due diligence on the programs to sign the required certificates.
I agree that the waterfall computer program proposal is wildly unpopular among issuers, underwriters and vendors of proprietary software. Investors seem split with some finding existing proprietary solutions sufficient, others wanting issuers to have liability for the output of those commercial models and yet others suggesting that the same model used for actual distributions be made available at the time of sale.
I also agree that a loan level approach doesn't work for revolving asset pools. But for the run of residential mortgage backed securities, the difficulties have been greatly exaggerated.
1. The issuer's inability to create the model is a bogus issue. Almost all issuers are special purpose entities with no employees and operate solely as an insolvency cut-out. Their actual operations are carried out on their behalf by affiliates who are either investment banks servicing as underwriters or sponsors. In the relatively rare case of an issuer without a large financial institutional affiliate operate as part of a kaizen. Someone in the chain of distribution of these securities always has the capacity to model pools at a loan level. That's how they hedge them in pipeline.
2. Python is not the issue; otherwise, objectors would have suggested alternative programming languages.
3. The existing models already disaggregate pool data into "rep lines" that represent weighted averages and subtotals of various subgroups of loans. If you can run a model on 16 composite loans you can run the same model on 1,600 individual loans.
4. The SEC proposal does not establish a standard of precision (or even accuracy), which remains materiality. Worries about the magnitude of differences between numerical results of a model and the actual cash distributed are imported from the fear of Section 11 liability. That was a problem addressed long ago with decrement table disclosure; you describe assumptions and limitations.
5. A model would only need to be updated if the governing instrument were amended to change the paydown rules or if it was discovered to be flawed (failed to produce the correct output given actual input). Nothing in the SEC proposal requires customer support.
6. Unlike narrative disclosure (misplaced modifiers are not self-detecting), the majority of programming errors are obvious--the program just won't run. If a program is well formed but wrong (adding when subtracting is called for) the misstatement should be treated like any other and evaluated for materiality. Also, an issuer is no more liable for an investor who is unable to read computer code than one who is unable to read English. (And no less.)
7. There is no reason to believe that issuer liability would attach to a statement by an investor that resulted from an assumption provided by the investor, even an assumption that was reasonable. So long as the model works mechanically, "all" the issuer and underwriter have to worry about are omissions about the scope of the model.
The outcry against the proposal is a self-indictment. The industry is either saying that it really doesn't know how these deals work or doesn't want it to be checkable.
"Anything we can explain to a computer is science. Everything else is art." Donald Knuth, famous computer scientist.
Thank you for your comment. I am obviously in no position to debate the relative merits of the technical arguments. It nonetheless remains the case that the proposed requirements add complexity, cost and confidentiality issues that may discourage the use of a financing format that has been successful in reducing the costs of consumer and commercial credit. In the context of US RMBS, the addition of more restraint in the use of such funding programs is clearly merited. In the context of the other jurisdictions and other classes of ABS, it may simply slow the freeing of credit availability that is urgently needed to nudge along a stubbornly halting economic recovery. On the liability issues, you might want to refer to our piece to be posted today for further discussion.