The SEC and the Python

Last week, the SEC put out a 667 page proposal regarding disclosures for asset backed securities. What I found exciting was this:

We are proposing to require that most ABS issuers file a computer program that gives effect to the flow of funds, or “waterfall,” provisions of the transaction. We are proposing that the computer program be filed on EDGAR in the form of downloadable source code in Python. ... (page 205)

Under the proposed requirement, the filed source code, when downloaded and run by an investor, 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, including but not limited to assumptions about future interest rates, default rates, prepayment speeds, loss-given-default rates, and any other necessary assumptions ... (page 210)

The waterfall computer program must also allow the use of the proposed asset-level data file that will be filed at the time of the offering and on a periodic basis thereafter. (page 211)

This is absolutely the right way to go particularly when coupled with the other proposal that detailed asset level data be also provided in machine readable (XML) format. For a securitization of residential mortgages for example, the proposal requires disclosure of as many as 137 fields (page 135) on each of the possibly thousands of mortgages in the pool.

Waterfall provisions in modern securitizations and CDOs are horrendously complicated and even the trustees who are supposed to implement these provisions are known to make mistakes. A year ago, Expect[ed] Loss gave an example where approximately $4 million was paid to equity when that amount should have been used to pay down senior notes (hat tip Deus Ex Macchiato).

Even when the trustees do not make a mistake, the result is not always what investors had expected. A few months ago, FT Alphaville reported on two Abacus deals where the documentation allowed the issuer (Goldman Sachs) to use its “sole discretion” to redeem the notes without regard to seniority. People realized that this was possible only when Goldman Sachs actually paid off (at face value) some junior tranches of these CDOs at the expense of senior tranches.

When provisions become complex beyond a point, computer code is actually the simplest way to describe them and requiring the entire waterfall to be implemented in open source software is a very good idea. The SEC does not say so, but it would be useful to add that if there is a conflict between the software and textual description, the software should prevail.

Now to the inevitable question — Why Python? The SEC actually asks for comments on whether they should mandate Perl, Java or something else instead. I use Perl quite extensively, but the idea that Perl is a suitable language for implementing a transparency requirement is laughable. Perl is a model of powerful but unreadable and cryptic code. As for Java and C-Sharp, there is little point in having open source code if the interpreter is not also open source. I do not use Python myself, but it appears to be a good choice for the task at hand.

It is gratifying that the SEC continues the one good thing that Cox initiated when he was Chairman – the use of technology as a key regulatory tool.

Posted at 6:25 pm IST on Fri, 16 Apr 2010         permanent link

Categories: bond markets, derivatives, regulation, technology

Comments