April 24, 2010

When the Python meets the Mongoose ... the SEC and programming Asset Backed Securities

Twan points to an odd thing from the Securities and Exchanges Commission in USA:

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)

An ABS or asset backed security is a basically a financial instrument that has or "owns" a lump of property. In short, instead of owning the property yourself, you own a security (or instrument or contract) that has an interest in the property. At the simplest, trivial level of own house, one instrument, this is mostly meaningless, because the instrument owns the property so you may as well own it directly.

But it allows for more complexity. What they are talking about here is securitized home loans and the like, essentially the instruments that blew up in the recent financial crisis. In this case, your instrument has an interest in 1000 properties, but also this is the same interest that another 10,000 instruments have. So you don't own a house, or a tenth of a house, you own a share in the revenues of a combined 1000 houses.

What is that revenue? Well, it is probably the mortgage payments on the 1000 houses. Every month, the mortgage payments are collected, aggregated, fees taken, then the payments out are sent to the instrument holder.

So what the SEC is on about is complicated formulas. Also, they change. If 10 of the houses are delinquent this month, then 20 next month, the money changes. If interest rates go up, again it changes. If fees change, more change. Indeed, it's pretty clear that there is much more complexity and change than there is stability.

So the SEC is seeking to encourage the manager to show the formulas. In a computer program, so we can plug in the numbers, and investors can play around to isolate their preferred situations. On the surface it is a good idea. It gives the investor more power, and it sets up a key disclosure which can likely be challenged in the event of trouble. But it is unlikely to work as a mandated thing.

There are several things against this. Complexity is the enemy here. There are two ways of looking at it, as too complex, and as not complex enough. Initially, the models will be simple, but this will just set the scene for disputes, and the models will get more complex. And then more complex again because the hidden-by-complexity bug will strike -- managers will realise that if they make the models so complex that nobody can deal with them except real experts, then they'll be both compliant and impenetrable, and can get back to their normal games. If you look long enough at the financial crisis, you'll see that one important factor is complexity, and worse, deliberate complexity. This is an old game.

Further, there is a bit of a trap for young players here (as explained to me by Jim). The model will display the "flow of funds" which is in turn dictated by the instrument (the contract). Servicing and pooling provisions in the contract will mandate the manager's actions, and therefore the cash flow. So measuring & comparing the cash flow in this way tells us the manager is meeting targets, etc, *but it tells us nothing about the underlying collateral* which is the true asset in the picture. Recall, again, the financial crisis: meeting targets and bonuses was part of the problem, not the solution. These agreements are written to provide plenty of scope for this sort of trouble, and the SEC's invention runs the risk of making this worse, not better.

What's the solution? Well, the real health of the fund to which your instrument draws on is based on the collateral, and the revenues from it. That is, the real information you want is detailed income, not aggregated outgoings. So if the SEC were to want to make a difference, what it should do is mandate that the anonymised income transactions be made available (FCers will know what that means). That is, any time a house-owner makes a payment into the fund, that transaction be published to the fund investors. By tracking month to month the payments, and matching that to what the investors get, we have some data of value.

Would they do this? The SEC is not going to propose this, because of the complexity argument. The industry will not give up any of its treasured complexity, because that's how it makes money. If you could see what was going on, the prices would be beaten down.

But it could be done voluntarily. A private player could set this up; we have all the tech and understanding to do this. So what could the SEC do? Expand its proposal slightly, and create a format for a fund to reveal the anonymised flow of incomes from the collateral. And provide a program to deal with that. And see if anyone bites...

Meanwhile, two postcripts on spotted observations. One: a group of language specialists think the SEC are trying to give formal definition to the instrument; by means of Python. No, they're on the wrong track. Firstly, that isn't what the SEC is trying to do. Secondly, it won't work because bonds by their nature are contracts, and formal proofs of contracts are the domain of the courts, not compilers. Although this concept has been explored, real world bonds still have more to do with my Ricardian Contract form than esoterica like Nick Szabo's smart contracts.

Two: another group of developers are arguing whether Python is the right language. No need to comment :)

And Three, added from next post, maybe this is to happen:

The companies selling the bonds would also have to give the government extensive information, in a form that is easily searchable, on all of the individual loans that make up the portfolio behind the bond offering, and update it on a continuing basis. Previously, reports were required only on the overall credit quality of the pool of loans, and for some bonds, updates were suspended after about a year. .... Ms. Casey also expressed concerns about the impact of the rules on personal privacy, asking whether “data miners” might be able to use the information on individual loans to determine the identification of loan holders.

Spotted in NYT article.

Posted by iang at April 24, 2010 09:15 AM | TrackBack

I don't think it's a bad idea. It'd save everyone a lot of re-implementation, and the maths for the waterfall is likely to be clearer than the prose.

Not sure about Python. MatLab is the "industry standard" (ok, more people use Excel, but we don't want that) modelling tool. By far the best treatment of financial contract & programming I know of was in Haskell.

But you're right, it's the assets, not the waterfall, that were the issue. People didn't go out and check things in real-life - and there was no incentive to.

I have suggested trading at the level of individual mortgages, with tranches sliced through the mortgage itself, rather than a pool.

For as long as banks are concentrating on gaming their capital requirements, and pension funds on minimising their contributions, there's no incentive to start doing things accurately.

Posted by: Thomas Barker at April 25, 2010 02:05 PM

"formal proofs of contracts are the domain of the courts, not compilers."

Of course the court's answers can differ from the computer's, and the court's are legally authoritative, but the same is true for courts and contracts vs. accountants and their spreadsheets. What is reported on a financial statement is an extreme simplification of what is actually in a company's contracts.

What the SEC seems to be trying to do, and what traders on Wall Street has been doing for many years, is to move beyond spreadsheets to summarize the value of contracts like derivatives, which can be highly inaccurate, to accountants and programmers using algorithms to summarize the value of these kinds of contracts, which can be far more accurate. Python makes for a great improvement for these purposes over the formulas in a spreadsheet, although my own contract language (or its successor in the works) would be better as unlike Python it easily models the temporal relations in a contract.


Posted by: nick at April 25, 2010 02:35 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.